Subject: Re: [boost] CGI / FastCGI library update
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-20 03:04:24
> > - Unix domain sockets - MUST
> As noted in the docs, this is a future goal. What makes
> them such a necessity?
Because they are much more efficient then TCP/IP onces,
so if you deploy application on Unix you will want to use them.
They also have several other advantages like not colliding with other
application when listening on same port accidentally.
> As I see it, recompiling just to use Unix sockets instead
> of TCP is
I agree that there is no reason to do this for FastCGI and CGI
(even official libfcgi supports it) but if you once
implement SCGI you will want to be able to switch between FCGI/SCGI
> Indeed. I started support for SCGI in the past but have
> removed those parts
> for now since they aren't complete. Adding support is just
> a matter of
> fnding the time as the design of the library should support
I fully understand this, I just suggested, not SCGI protocol is so
simple that it can be implemented in several hours. (At least
that what It had take for CppCMS)
> I agree that I18N support is a must, but unfortunately I'm
> pretty ignorant
> with respect to Unicode. Every char and string in the
> library derives from
> the traits of the protocol being used, so this is
> configurable throughout
> the library, but I have not done any more to support them.
> I think
> basic_char<wchar_t> is the only typedef that uses
> wchar_t and it isn't used
Once again, don't try to leave in illusion that support of wide
character would give you any advantage in Unicode support.
> > - You must parse cookies inside quotes as well.
> > Cookie as foo="×©×××" is actually valid
> Interesting, I wasn't aware this was valid for receiving
> cookies on a
> server. Do you have a reference for this?
Take a look on: http://www.ietf.org/rfc/rfc2109.txt
I would generally recommend always refer to proper RFC.
> > Session managements I would strongly not recommend you
> > using boost::serialization for this purpose. Performance
> > is terrible (from my experience).
> What would you suggest as an alternative?
Use key value pairs as they most popular data stored in sessions.
And allow value be serializeable object for complex data structures.
> I think supporting lexical conversion is a requirement of
> any CGI library,
> so the as<> and pick<> data access functions
> are provided for this use. In
> the absence of better an alternative, if these two
> functions were documented
> with caveat about lexical_cast, would that be sufficient?
You can always use std::stringstream (what lexical_cast is actually
uses) but you must imbue std::locale to the stream like this.
Number to_number(std::string const &s)
ss >> r;
if(!ss) throw ..
> Indeed, I am testing with lighttpd and nginx at the moment.
> I have found an
> experimental plugin for for nginx that supports "proper"
> multiplexing too,
> which looks promising.
Few words about multiplexing:
1. There is not a single web server that implements multiplexing
as it much simpler and efficient to just open another socket.
2. More then that the only web server I have ever seen using Keep-Alive
was cherooke (and I think IIS over pipes because pipes are not sockets)
3. Even official fastcgi library do not support multiplexing.
4. There is always way to tell to web server if application supports
multiplexing or not. (on of commands of fcgi)
5. There is deep problem with multiplexing as there is no way
to tell fastcgi application that it can't send data meanwhile
For example you have two clients downloading big csv file
of 1G one has connection slower in two times then other.
So if they have multiplexed connection then either both clients
will revive data at the lowest speed or web server will have to store
about 0.5G in its internal buffers.
So multiplexing is generally bad idea.
My suggestion - don't waste your time on it. It useless feature
that theoretically could be useful but nobody uses it.
Also fastcgi specifications allow you as library developer not to support
multiplexing (actually I hadn't seen any fastcgi client that implements
> CgiCC is not compatible with the BSL so I can't use it. It
> also does not
> support lazy loading of requests or multiplexed FastCGI,
> which have always
> been goals of this library.
As I mentioned before multiplexed FastCGI exists only on paper.
Don't waste your time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk