CGI/FastCGI library preview
Hi everyone, Some of you may remember the CGI library that was being worked on for last year's GSoC. It still needs *loads* of work before it could be considered ready for review, but I think it's moved on far enough since I last updated this list that some more feedback would be very useful. Pre-built docs are online: http://cgi.sf.net/doc Current source is at: *http://tinyurl.com/2bsbsf* (browser-friendly) *http://tinyurl.com/2xcye2* (check-out) ** This is alpha-grade source: functional and ugly ** The examples there have been tested on ubuntu with gcc 4.1.2 and gcc 4.2 and on windows with MSVC 9. The FastCGI examples will only work on linux for now. I've not managed to get it working with lighttpd as-is but it seems to work fine on Apache 2.2 with mod_fastcgi or mod_fcgid (and shows some healthy benchmarking results). Any and all comments/suggestions/criticisms are welcome. Kind regards, Darren
Darren Garvey wrote:
Hi everyone,
Some of you may remember the CGI library that was being worked on for last year's GSoC. [...] Any and all comments/suggestions/criticisms are welcome.
Identifiers with only capitals are usually reserved for macros. Therefore GET/POST/whatever aren't such good names, IMO. The documentation doesn't say much but how to write examples that don't do anything HTTP-related. I have only read it quickly, so I may be wrong on my assumptions. From the examples, it seems you have to manually write the HTTP headers and that nothing is buffered. Not quite what I'd expect. I think output should be buffered up to a certain size. If everything fills in the buffer, use Content-Length. Otherwise, use chunked-encoding. Pluggable gzip or deflate encoding should be available, too. A mechanism to generate some hash depending on the whole output can be interesting, because you can use it as an etag and recognize it with if-none-match, thus allowing easy bandwidth saving. By the way, I couldn't find a way to read the headers provided by the request. Is it part of the input data?
Hi Mathias, On 30/03/2008, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Identifiers with only capitals are usually reserved for macros. Therefore GET/POST/whatever aren't such good names, IMO.
Ok, good point. I just recently added an operator[] overload to basic_request<> which means instead of: req.GET("whatever"); you can do: req[get_data]["whatever"]; I was wondering about removing the GET/POST/etc. member functions entirely, you've probably just convinced me. :-) The documentation doesn't say much but how to write examples that don't
do anything HTTP-related. I have only read it quickly, so I may be wrong on my assumptions.
Unfortunately the docs are pretty terrible at the moment - I just stuck them up because of the examples really. I'm not sure what you mean about "examples that don't do anything HTTP-related". From the examples, it seems you have to manually write the HTTP headers
and that nothing is buffered. Not quite what I'd expect.
Everything is buffered in the `response` object: the idea is that you can reuse one response for a number of different requests. Also, you can write response headers using: response resp; resp<< content_type("text/plain") << header("arbitrary-header-name", "some-value"); Adding a default "Content-type" header is easy enough to do, but I'm not sure of the value of that. How did you expect to write the HTTP headers? I think output should be buffered up to a certain size. If everything
fills in the buffer, use Content-Length. Otherwise, use chunked-encoding. Pluggable gzip or deflate encoding should be available, too.
Ahh, this isn't an HTTP library - it only does CGI and FastCGI (and SCGI eventually). Chunked-encoding and compression aren't available to these protocols. A mechanism to generate some hash depending on the whole output can be
interesting, because you can use it as an etag and recognize it with if-none-match, thus allowing easy bandwidth saving.
Some sort of hash-making facility could be used for checking requests against a cache of stored responses too. Could be very useful! I wonder if someone has offered to finish the Boost.Crypto library that Kevin Sopp started? (link: *http://tinyurl.com/ywy2ha* ) By the way, I couldn't find a way to read the headers provided by the
request. Is it part of the input data?
Yep. The basic headers are the 'environment variables'. They're stored/accessed like so: cgi::request req; req.load(); cgi::map& environment_vars = req[env_data]; The echo example might be what you want: *http://tinyurl.com/2594sf* A cgi::map is at the moment just a std::map<string, string>, so you can just use them directly. Thanks for the feedback, Darren
On 30/03/2008, Darren Garvey <darren.garvey@gmail.com> wrote:
On 30/03/2008, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Identifiers with only capitals are usually reserved for macros. Therefore GET/POST/whatever aren't such good names, IMO.
Ok, good point. I just recently added an operator[] overload to basic_request<> which means instead of:
req.GET("whatever");
you can do:
req[get_data]["whatever"];
Apologies to those who tried and failed compiling the examples... It seems I merged these changes into the examples but not the headers. Should be fixed now. Regards, Darren
participants (2)
-
Darren Garvey -
Mathias Gaunard