At 11:13 AM 6/20/2005, jean-frederic clere wrote: >William A. Rowe, Jr. wrote: >>At 08:55 AM 6/20/2005, jean-frederic clere wrote: >> >>>jean-frederic clere wrote: >> >>>>and GET with content-length. >>> >>>I think that is not forbidden in the rfc... >>>But what about returning HTTP_BAD_REQUEST if Content-Length is not 0? >> >>See section 4.3 of RFC 2616. >>Content-Length: 0 signals a message body of 0 bytes, not the >>absence of a message body. It shouldn't be treated differently >>from Content-Length: n. > >OK, HTTP_BAD_REQUEST if C-L is present in GET?
I don't think so; 9.3 does not exclude it. Any extended XML resource description could require it. The only method which prohibits message bodies is TRACE. I believe this is one case where we need to absolutely follow the letter of RFC2616, and expect the backend to do the same. I would not object to some additional flag in the <Proxy > block which restricts message bodies in various ways, as an optional feature as opposed to being 'stricter than the RFC'. The changes to T-E and C-L will undoubtedly break some home brew request submission code. At least when things break, let's have the RFC to fall back on, that we 'did the right thing' with respect to request bodies. Bill
