On Sun, 2002-09-29 at 19:31, Ryan Hoegg wrote: > Hi Edd, > > I've been working on this some more and have formed my latest theory as > to what's gone wrong. I think both the Apache distribution and this one > are breaking the HTTP 1.1 spec in RFC2616: > > You: > - Messages MUST NOT include both a Content-Length header field and a > non-identity transfer-coding. > and > - The Content-Length header field MUST NOT be sent if these two lengths > are different (i.e., if a Transfer-Encoding header field is present).
Hmm, that makes it an interesting problem to solve this end -- as this behaviour is entirely dependent, as far as I can see, on the host web server. In my case, Apache 1.3. The only thing I could think to do would be to instruct users to ensure they force HTTP 1.0 on their XML-RPC endpoint (I don't even know if this is possible, I've only ever seen this enforced in Apache httpd via the BrowserMatch directive). > Us: > - If the message does include a non-identity transfer-coding, the > Content-Length MUST be ignored. > and > - If a message is received with both a Transfer-Encoding header field > and a Content-Length header field, the latter MUST be ignored. As obviously there appears to be no guarantee for you that servers using PHP XML-RPC will do the right thing, and I don't appear to be able to make a change to enforce it, then I think it's up to you... All suggestions for workarounds welcome. -- Edd
signature.asc
Description: This is a digitally signed message part
