RE: Resend: Re: IPP> Chunked POST: SUMMARY

Although this seems like an important clarification, I don't think
it fits simply as an editorial change. If it's worth pursuing this
at all, it will belong in another document (a HTTP implementation
guide?) or in the HTTP/1.1 revision for "Standard".

================
> I'd like to propose that the wording be clarified in the spec.  I have
> encountered servers that "accept" a chunked POST with 200 (OK) and
then
> silently discard the message body, passing a zero-length entity-body
to the
> service layer (CGI or servlet), so I think some implementors are
> misinterpreting the current wording.
>
> I propose adding something along these lines:
> "If a server disallows message bodies encoded with the chunked
> transfer-coding in requests to some resource, it MUST return an error
code
> in the response to such requests.  If this is the primary reason for
> rejecting a request, the response MUST contain the 411
> (Length Required) error code."
>
> Also, this sentence should be reworded:
>
> Section 4.4, Message Length:
> All HTTP/1.1 applications that receive entities MUST accept the
“chunked”
> transfer-coding (section 3.6), thus allowing this mechanism to be used
for
> messages when the message length cannot be determined in advance.
>
> becomes something like:
>
> All HTTP/1.1 applications that receive entities MUST understand the
> “chunked” transfer-coding (section 3.6), thus allowing this
> mechanism to be used for messages when the message length cannot be
> determined in advance.
> This does NOT mean that servers must accept messages containing bodies
> encoded with the chunked transfer-coding.

Received on Saturday, 27 February 1999 17:11:02 UTC