Subject: Re: [boost] CGI / FastCGI library update
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-19 05:14:01
> I have packaged a version of a CGI / FastCGI library* up to
> sourceforge and
> would very much appreciate feedback and critique from
> interested parties.
> Feedback from this list has been invaluable in the past.
I had take a look in the project in about half an hour.
I have **very good** experience in C++ web application/libraries
development as I'm an author of CppCMS. So I took a look especially
at points I know that tend to be weak.
Please describe what is your final target.
- Unix domain sockets - MUST
- Make request abstract class rather then concept. Unless you
want to recompile your application to work with each type of connection.
I you only what to change configuration if you work over Unix sockets,
TCP sockets or you work with scgi instead of fcgi.
Beleive me I've been there I know what I'm talking about.
The way asio works fine for work for general cases of implementing
specific protocols but very bad for applications that may work
with different sources of data
So if I would be doing formal review I would say that this is no-go
- I'd recommend you also implement SCGI as it is very simple
and very similar to fcgi in abilities.
- You need to handle signals: http://www.fastcgi.com/docs/faq.html#Signals
This is how web server would shutdown your application:
- What is basic_cookie<wchar_t> ? Have you seen anything like that in RFC?
How would you convert octets cookie to wide? What encoding? What library
do you use for code-page conversion?
Just use plain string.
Don't try to push wchar_t to your application as you'll get in deep
troubles. Want Unicode? Use UTF-8 and stay away from "wide characters"
they would may your life much harder and would not bring you a single
advantage over UTF-8.
I've been there too...
You need acceptors to be configurable to work with:
- Unix domain sockets from arbitrary external socket and **stdin**
- TCP/IP sockets from arbitrary port and **stdin**
- Use max age rather then expiration date, it is much more reliable
accorss various system with unsichronized clocks.
- You must not URL-Decode cookies (see apropriate RFC)
- You must parse cookies inside quotes as well.
Cookie as foo="×©×××" is actually valid cookie.
- Not thread safe. The code you written is no-go. You need to do
some hard work to make it safe.
- Session managements I would strongly not recommend you
using boost::serialization for this purpose. Performance
is terrible (from my experience).
But this is up to you.
- Don't use boost::lexical_cast for conversion between numbers and
string - you may be surprised what happens with it
when you start using localization... (bad things)
- Test with more then one web server: test with lighttpd and nginx
as you find some things different.
- I can say from the begging you will have problem with IIS. I don't
think IIS FastCGI connector is good enough today. You will probably
need to work over pipes.
IIS FastCGI has some TCP/IP support but I don't think it is mature
Now few additional unrelated points:
Take a look on two following projects:
- CppCMS (the web framework I develop)
The wiki is build on CppCMS.
- CgiCC is a cgi library (that supports fcgi as well)
and supports about almost everything you have in your code.
(maybe no sessions, but I don't think your session implementation
is not safe at least at this point)
I use this library in CppCMS 0.0.x but removed it
from CppCMS 1.x.x for several reasons.
Note they licensed under LGPL and not Boost license.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk