Boost logo

Boost :

From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2008-03-30 16:55:07

Hi Mathias,

On 30/03/2008, Mathias Gaunard <mathias.gaunard_at_[hidden]> 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:


you can do:


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

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: ** )

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;
cgi::map& environment_vars = req[env_data];

The echo example might be what you want: **

A cgi::map is at the moment just a std::map<string, string>, so you can just
use them directly.

Thanks for the feedback,

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