IPP Mail Archive: Resend: Re: IPP> Chunked POST: SUMMARY

IPP Mail Archive: Resend: Re: IPP> Chunked POST: SUMMARY

Resend: Re: IPP> Chunked POST: SUMMARY

kugler@us.ibm.com
Tue, 19 Jan 1999 17:15:57 -0700

To the HTTP WG from the IPP WG:

I've tried to post this twice before, but it never makes it into the
archives at

http://www.ics.uci.edu/pub/ietf/http/hypermail/

or

http://www.findmail.com/listsaver/http-wg/

The IPP WG would really like clarification on this point: Is the intent of
the HTTP/1.1 spec to say that an HTTP/1.1 server MAY reject any request
without a defined Content-Length? This would imply that a conformant
HTTP/1.1 server MAY reject any request with the "chunked" transfer-coding.

-Carl Kugler

---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/12/99
04:33 PM ---------------------------

Carl Kugler
01/07/99 08:27 AM

To: CGI-WG@Golux.Com
cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, SERVLET-INTEREST@JAVA.SUN.COM
From: Carl Kugler/Boulder/IBM@IBMUS
Subject: Re: IPP> Chunked POST: SUMMARY (Document link not converted)

Ross Patterson wrote:

>>> 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.
>>
>>Apparently that should be interpreted as "MUST accept the 'chunked'
>>TRANSFER-CODING, but NEED NOT accept REQUESTs with that transfer-coding."

>Correct - all HTTP 1.1 servers must be able to process requests encoded
>as chunked data, but they are still allowed to refuse the request for
>other reasons.

To me, the presence of the 411 status code means that an HTTP/1.1 server
MAY refuse to accept a request for the specific reason that entity body is
encoded with the "chunked" transfer-coding:

411 Length Required
The server refuses to accept the request without a defined Content-Length.
The client MAY repeat the request if it adds a valid Content-Length header
field containing the length of the message-body in the request message.

-Carl