Re: [boost] CGI / FastCGI library update

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: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#myths

> > - 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: 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.

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