httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Dealing with MS Web Publishing Wizard
Date Wed, 16 May 2001 01:56:55 GMT

In a message dated 01-05-16 01:01:44 EDT, Roy Fielding writes...

> Subj: Re: Dealing with MS Web Publishing Wizard 
> Date: 01-05-16 01:01:44 EDT
> From: fielding@ebuilt.com (Roy T. Fielding)
> Reply-to: new-httpd@apache.org
> To: new-httpd@apache.org
> CC: enzo@hk.net
>  
>  >Following a suggestion by a Usenet user, I'm forwarding you my findings
>  >about an incompatibility between Apache (v. 1.3 at least) and Microsoft 
Web
>  >Publishing Wizard.
>  >[...]
>  >OK, I have understood what it happens, but I don't know how to fix it.
>  >
>  >Briefly, WPW violates HTTP 1.1 specs in three points:
>  >
>  >--- 1. WPW expects a "100 Continue" response from the server, but it 
> forgets
>  >to request it with the due "Expect: 100-continue" header. RFC2616, in the
>  >section 8.2.3, says:
>  >
>  >      - If a client will wait for a 100 (Continue) response before
>  >        sending the request body, it MUST send an Expect request-header
>  >        field (section 14.20) with the "100-continue" expectation.
>  
>  That could be detected by the user agent field and worked-around.

That would explain why Microsoft's IIS Server will ALWAYS send
a '100-Continue' response for any POST transaction with data that
exceeds 12,000 bytes.

This is not really a protocol violation.

There is an 'exception' to the rule you are quoting and IIS is using it.

I am quoting just a few paragraphs down from where you are
quoting the same HTTP/1.1 RFC...

[snip]

     - An origin server SHOULD NOT send a 100 (Continue) response if
       the request message does not include an Expect request-header
       field with the "100-continue" expectation, and MUST NOT send a
       100 (Continue) response if such a request comes from an HTTP/1.0
       (or earlier) client. There is an exception to this rule: for
       compatibility with RFC 2068, a server MAY send a 100 (Continue)
       status in response to an HTTP/1.1 PUT or POST request that does
       not include an Expect request-header field with the "100-
       continue" expectation. This exception, the purpose of which is
       to minimize any client processing delays associated with an
       undeclared wait for 100 (Continue) status, applies only to
       HTTP/1.1 requests, and not to requests with any other HTTP-
       version value.

[snip]

Basically, the RFC makes it perfectly fine for a Server to send a 
'100-Continue'
message anytime it wants during a PUT or a POST, even if the Client didn't 
ask for it. 

In order to be fully RFC compliant a proxy MUST be coded to handle the 
'unexpected
100-Continue'. It really requires that POST handling be 'full duplex' and the
Server has to be checking for it to arrive from the other side at any moment
during the POST transaction. The deadly sin would be to let the '100-Continue'
float into the response buffers unnoticed and not check to see if it was 
there before
sending back the 'real' response. The Newtwork card might actually accumulate
'2' responses to the POST before some Servers will get back to reading the
downstream connection and if you don't notice that there are now '2' response
headers sitting back to back in the NIC buffer ( 100-continue + 200 OK ) then
most response parsing logic will treat the 100-Continue as the response to
the entire post and the SECOND header ( the real 200 OK response ) as
BODY DATA for the 100-Continue. Not good. )

The only way to really make this work, since it's actually LEGAL as per RFC,
is to just make damn sure you recognize that the 'unexpected' 100-Continue
is not the REAL response to the POST transaction. If the User-Agent isn't
going to be able to handle the unexpected '100-Continue' then you have to
throw it on the floor and only send back the 'real' response to the POST.

>  >--- 2. WPW then sends a dummy "Content-lenght: 0", whereas the section 4.4
>  >of RFC2616 states:
>  >
>  >   When a Content-Length is given in a message where a message-body is
>  >   allowed, its field value MUST exactly match the number of OCTETs in
>  >   the message-body. HTTP/1.1 user agents MUST notify the user when an
>  >   invalid length is received and detected.

I have seen lots of POST transactions coming from User-Agents that 
have a 'Content-length: 0' field... but it usually means what it says...
the POST data length is ZERO and there really isn't any data.

A lot of HTML forms I've seen will resort to using a POST but if the
user has clicked on 'Submit' without filling out the form there really isn't
ANY data to send back and that's why 'Content-length:' can be ZERO
and the POST floats back anyway.

If WPW is really, truly, sending a POST transaction with a Content-length
of ZERO and is NOT also indicating 'Transfer-Encoding: chunked' and
there really is some amount of DATA going back to the Server... then
yeah... it's totally broken. I can't imagine how that would EVER work
especially if 'Keep-Alive' is being used. How in the hell would ANY
Server know where the end of the post data is? You can't use the
'just close the connection' scheme for requests because... well... you
just CAN'T. If the User-Agent closes the connection like a Server
would thinking that's supposed to mean END OF POST DATA then
someone needs to clue the author in that it really means
END OF CONVERSATION.

>  That is just too broken to bother making a work-around.  Basically, this
>  client won't work on any network with proxies, gateways, or valid origin
>  servers, so there is no point in us thinking about it.  Microsoft will
>  have to fix their bugs before WPW can be a usable tool.
>  
>  ....Roy

It DOES work through proxies... as long as that Proxy is coded to handle
the 'unexpected 100-Continue' responses from the Server which the RFC
says is 'legal' and can happen at any time.

Again... that 'unexpected 100-Continue' is made legal by this...

[snip ]

There is an exception to this rule: for
compatibility with RFC 2068, a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
continue" expectation.

[snip]

Whenever IIS is told that more than 12,000 bytes of POST data is
headed its way... it ALWAYS sends '100-continue' in the middle
of the POST process shortly after receiving the first 4k of data
whether there was an 'Expect-continue:' field or not.

It looks like IIS is really trying to establish 'flow control' since
it's using 4k internal buffers.

Hit IIS with ApacheBench and send 14,000 bytes of POST data
and you will see it for yourself.

Yours...
Kevin Kiley


Mime
View raw message