You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2002/09/29 20:31:27 UTC
Re: [phpxmlrpc-devel] Interoperability
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).
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.
--
Ryan Hoegg
ISIS Networks
Edd Dumbill wrote:
>OK, I figured this out. Your request header has HTTP/1.1 in it. If
>that's what you send, that's what the web server expects you to speak!
>
>The ones your program worked against worked because they don't implement
>HTTP/1.1.
>
>Change your request to HTTP/1.0, or implement HTTP/1.1 properly :)
>
>-- Edd
>
>
Re: [phpxmlrpc-devel] Interoperability
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Sorry, messed up the cross post. Should have gone to Jakarta Commons
Dev. Please disregard.
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).
>
> 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.
>
> --
> Ryan Hoegg
> ISIS Networks
>
>
> Edd Dumbill wrote:
>
>> OK, I figured this out. Your request header has HTTP/1.1 in it. If
>> that's what you send, that's what the web server expects you to speak!
>> The ones your program worked against worked because they don't implement
>> HTTP/1.1.
>>
>> Change your request to HTTP/1.0, or implement HTTP/1.1 properly :)
>>
>> -- Edd
>
Re: [phpxmlrpc-devel] Interoperability
Posted by Edd Dumbill <ed...@usefulinc.com>.
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
Re: [phpxmlrpc-devel] Interoperability
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Sorry, messed up the cross post. Should have gone to Jakarta Commons
Dev. Please disregard.
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).
>
> 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.
>
> --
> Ryan Hoegg
> ISIS Networks
>
>
> Edd Dumbill wrote:
>
>> OK, I figured this out. Your request header has HTTP/1.1 in it. If
>> that's what you send, that's what the web server expects you to speak!
>> The ones your program worked against worked because they don't implement
>> HTTP/1.1.
>>
>> Change your request to HTTP/1.0, or implement HTTP/1.1 properly :)
>>
>> -- Edd
>
Re: [phpxmlrpc-devel] Interoperability
Posted by Edd Dumbill <ed...@usefulinc.com>.
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