Re: [Chicken-users] proposed change to http-client

[Elf]

On Wed, 13 Feb 2008, Graham Fawcett wrote:

> On Feb 13, 2008 11:05 AM, Elf <address@hidden> wrote:
> > > Here, http:POST overwrite Connection header in req.
> > > I guess correct behavior is of http:GET,
> > > because with HTTP/1.1 the absence of the Connection header
> > > means keep-alive.
> > > a
> > > Oh, or are you saying that http:POST should ALWAYS close connection?
> >
> > i was saying that i thought it should always lose connection, but graham
> > pointed out that i was incorrect.
>
> In fairness, in HTTP 1.0 you are correct (if overspecific). :-)
>
> > theres a separate issue of 1.0 being default though.
>
> Right. It takes a lot more work to write a correct HTTP 1.1 client;
> there are many new issues that are considered "MUSTs" in RFC-speak:
> 307 redirects, transfer encoding, etc.

hm, this is offtopic of course, but methinks it would be easier to do many
of the requirements in scheme than in other languages.... transfer 
encodings are just procedure dispatch + composition, for exmaple. 
i have to be honest, though, i have no clue what a 307 is, ive never 
encountered one and dont remember it from the rfcs at all (and it should be
abundantly clear from earlier conversation today that my memory of them is
flaky at best).


back to original topic, though: 
a) are the changes generally useful (ie should they be kept)
b) are there other specific changes or flaws in the submitted implementation
   that need to be addressed? (assuming a is met)
c) should the changes be backported, assuming a and b are satisfied?

-elf


> The curl egg gives us low-level libcurl bindings; if we want a
> complete HTTP 1.1 client implementation, I'd suggest that curl is the
> best foundation.
>
> In short, it's a question of what we want the http-client module to be
> when it grows up. Implementing a full HTTP 1.1 client is probably not
> it. If we assume 1.0 semantics, we should close all connections, or
> use Keep-Alive and read the RFCs to make sure we are clear on the
> implications. (I confess, I can't remember *why* RFC 2616 suggested
> Keep-Alive wasn't a great idea, just that it did.)
>
> Graham