Re: Chunked transfer encoding on responses.

[Justin Erenkrantz]

On 4/8/07, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:

So why is there a dependency on keep-alive being enabled?


If keep-alive is disabled for the connection, then Connection: Close
tends to be more efficient anyway...  -- justin

Re: Chunked transfer encoding on responses.

[Henrik Nordstrom]

lör 2007-04-07 klockan 04:00 -0500 skrev William A. Rowe, Jr.:

> Of course this person is entirely wrong if the client doesn't
> Accept-Encoding: chunked
> 
> which is exactly the logic we test.

So why is there a dependency on keep-alive being enabled?

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: Chunked transfer encoding on responses.

[William A. Rowe, Jr.]

Justin Erenkrantz wrote:
> 
> Chunking support on a response is implicit if you claim HTTP/1.1
> support.  You don't need to signal it with Accept-Encoding (you can, I
> guess).  IOW, an HTTP/1.1 client should always a expect a server may
> give back chunking...  -- justin

Of course, my bad.  (Contrawise, if server is HTTP/1.1 client can expect
that an HTTP/1.1 request body will also be decoded if chunked.)

Re: Chunked transfer encoding on responses.

[Justin Erenkrantz]

On 4/7/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:

Graham Dumpleton wrote:
>
> The person on the WSGI list is more or less claiming that there would
> be no harm in a web server always applying chunked transfer encoding
> to a response which doesn't specify a content length

Of course this person is entirely wrong if the client doesn't
Accept-Encoding: chunked

which is exactly the logic we test.


Chunking support on a response is implicit if you claim HTTP/1.1
support.  You don't need to signal it with Accept-Encoding (you can, I
guess).  IOW, an HTTP/1.1 client should always a expect a server may
give back chunking...  -- justin

Re: Chunked transfer encoding on responses.

[André Malo]

* Henrik Nordstrom wrote:

> lör 2007-04-07 klockan 09:18 +0200 skrev André Malo:
> > Hmm, you may get something wrong here. The httpd does apply chunked
> > encoding automatically when it needs to. That is in keep-alive
> > situations without given or determineable Content-Length.
> >
> > Why doesn't it do it in all other cases? My answer is: because it would
> > be useless (as in: not of any use :-).
>
> I don't agree fully here. chunked is not useless in the non-keepalive
> case. What it adds there compared to the HTTP/1.0 method of just closing
> the connection is error detection. A receiver seeing the connection
> closed before the final "eof" chunk knows something went wrong and the
> response is not complete. If chunked is not used the receiver usually
> can not tell that there was a problem.

Ah, hmm. True :)

nd
-- 
"Solides und umfangreiches Buch"
  -- aus einer Rezension

Re: Chunked transfer encoding on responses.

[William A. Rowe, Jr.]

Graham Dumpleton wrote:
> 
> The person on the WSGI list is more or less claiming that there would
> be no harm in a web server always applying chunked transfer encoding
> to a response which doesn't specify a content length

Of course this person is entirely wrong if the client doesn't
Accept-Encoding: chunked

which is exactly the logic we test.

Re: Chunked transfer encoding on responses.

[Henrik Nordstrom]

lör 2007-04-07 klockan 09:18 +0200 skrev André Malo:

> Hmm, you may get something wrong here. The httpd does apply chunked encoding 
> automatically when it needs to. That is in keep-alive situations without 
> given or determineable Content-Length.
> 
> Why doesn't it do it in all other cases? My answer is: because it would be 
> useless (as in: not of any use :-).

I don't agree fully here. chunked is not useless in the non-keepalive
case. What it adds there compared to the HTTP/1.0 method of just closing
the connection is error detection. A receiver seeing the connection
closed before the final "eof" chunk knows something went wrong and the
response is not complete. If chunked is not used the receiver usually
can not tell that there was a problem.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: Chunked transfer encoding on responses.

[Graham Dumpleton]

On 07/04/07, André Malo <[EMAIL PROTECTED]> wrote:

* Graham Dumpleton wrote:

> Thus my question is, why when Apache was updated to support HTTP/1.1
> did it just preserve the HTTP/1.0 type behaviour and not in cases
> where it could automatically apply chunked transfer encoding to the
> response, apply it?

Hmm, you may get something wrong here. The httpd does apply chunked encoding
automatically when it needs to. That is in keep-alive situations without
given or determineable Content-Length.


So it seems. :-(

I dug into the code again and from that worked out that I had managed
to inadvertently disable it in my Apache configuration files by
commenting out the inclusion of extra/httpd-default.conf when I was
trying to debug some issue. Ie., the KeepAlive directive wasn't being
set.

Thanks for pointing out my mistake.

Graham

Re: Chunked transfer encoding on responses.

[André Malo]

* Graham Dumpleton wrote:

> Thus my question is, why when Apache was updated to support HTTP/1.1
> did it just preserve the HTTP/1.0 type behaviour and not in cases
> where it could automatically apply chunked transfer encoding to the
> response, apply it?

Hmm, you may get something wrong here. The httpd does apply chunked encoding 
automatically when it needs to. That is in keep-alive situations without 
given or determineable Content-Length.

Why doesn't it do it in all other cases? My answer is: because it would be 
useless (as in: not of any use :-).

nd
-- 
> [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
   -- Florian Hartig und Lars Kasper in dciwam