Boost logo

Boost :

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 > unacceptable, 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 without recompilation. > > 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 > an > implementation. > 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 > anywhere, Once again, don't try to leave in illusion that support of wide character would give you any advantage in Unicode support. See: > > - You must parse cookies inside quotes as well. > > Cookie as foo="שלום" is actually valid > cookie. > > > > 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: 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. template<typename Number> Number to_number(std::string const &s) { std::stringstream ss; ss.imbue(std::locale::classic()); ss.str(s); Number r; ss >> r; if(!ss) throw .. return r; } > > 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 multiplexing). > 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. Best, regards, Artyom

Boost list run by bdawes at, gregod at, cpdaniel at, john at