Re: [cpp-netlib-devel] TODO's in http_integration

[Dean M. B. <mik...@gm...>]

On Wed, Aug 13, 2008 at 3:45 AM, Divye Kapoor <div...@gm...> wrote:
>>
>> See section 4.2 - Message Headers of RFC 2616 (
>> http://www.faqs.org/rfcs/rfc2388.html ).
>> Headers can span multiple lines. This would require a change in the
>> processing of the headers.
>
> I meant http://www.faqs.org/rfcs/rfc2616.html
>

Okay, thanks. I'll look into it.

Perhaps we should have a test for that as well to make sure there's a
bug in the client in the first place. Can you make this happen with
the Python CGI script?

> Also, right now, we don't support the rather infrequently used TRACE and
> CONNECT methods. Maybe we should for the sake of completeness?
>

Right. This should be trivial given how the client code is structured right now.

> Another thing that struck me was the fact that using the just checked in
> example, if you try to access http://www.google.com - you get a redirect
> response (3xx status code). However, we don't automatically redirect. Should
> the choice to redirect be left to the user or should we give an option to
> enable automatic redirection? Personally, I am in favour of providing an
> option to enable or disable automatic redirection for requests. What do you
> think?
>

I was thinking about that. Actually, even if you just go to
http://boost.org/  you will get a redirect to http://www.boost.org/.

Right now the client does not have a constructor. We can make use of
the Boost.Parameter lib to make some of the options easily defined in
the client constructor -- like redirect, authentication information,
proxy, etc. I'm also thinking for having an overload to each method
that allows you to define these options in each call.

If we can have the Python CGI test return a redirect, perhaps we can
expose the bug and test it as well.

How's the POST handler going? :D

Thanks for the links and responses. They definitely help a lot.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.