On Thu, Jul 14, 2005 at 07:43:35AM -0400, Jeff Trawick wrote:
I'm so confused while trying to draw the line between
alternate RFC-compliant philosophy
fixes for actual RFC violations
fixes for security issues
I think CHANGES should be crystal clear on what change has a security
At 10:07 AM 7/19/2005, Joe Orton wrote:
On Thu, Jul 14, 2005 at 07:43:35AM -0400, Jeff Trawick wrote:
I'm so confused while trying to draw the line between
alternate RFC-compliant philosophy
Roy spelled it out, it's not in the RFC but if there is -any- way
we can use C-L, let's do it. The
* RFC 2616 says
All HTTP/1.1 applications MUST be able to receive and decode the
chunked transfer-coding, and MUST ignore chunk-extension
extensions
they do not understand.
I read this as an HTTP/1.1 server must accept chunked or quit
reporting it complies with the
At 06:34 AM 7/15/2005, Roy T. Fielding wrote:
All of it, except for the preference to RB_STREAM_CHUNKED when,
perhaps, we could be more sub-optimal, falling back on RB_SPOOL_CL.
Many RB_STREAM_CL choices, before, were equally dangerous, and that
C-L == length_read test in the
At 06:43 AM 7/14/2005, Jeff Trawick wrote:
On 7/13/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
How can I fix thee? let me count the ways...
* pass a chunked body always (no-body requests don't go chunked).
We tried to send C-L whenever practical because it is common for a
origin
