httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enzo Michelangeli">
Subject Dealing with MS Web Publishing Wizard
Date Tue, 08 May 2001 01:32:21 GMT

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.

IIS handles WPW's POST uploads through an ISAPI filter called Posting

For examples of its use, see e.g.:

Regards --

Enzo Michelangeli

----- Original Message -----
From: "enzo" <>
Sent: Friday, May 04, 2001 6:24 PM
Subject: Re: Content-length field in HTTP 1.1 and MS Web Publishing Wizard

Follow-up to my post of yesterday:

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.

--- 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.

This invalid content-lenght is parsed by Apache which closes the connection,
preventing any workaround at CGI level; and this is the real showstopper.
Perhaps WPW intends to pass size information by using chunked transfer
coding, but in that case RFC2616 (section 4.4) prescribes that the
"Content-lenght:" header be removed, and replaced by a "Transfer-Encoding:

   3.If a Content-Length header field (section 14.13) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length. 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). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored.

Facing the connection close, instead of mending its ways and retrying with a
plain HTTP 1.0 POST, WPW commits the third violation:

--- 3. WPW does not retry the connection closed by the server, despite
RFC2616 recommending:

 8.2.4 Client Behavior if Server Prematurely Closes Connection

   If an HTTP/1.1 client sends a request which includes a request body,
   but which does not include an Expect request-header field with the
   "100-continue" expectation, and if the client is not directly
   connected to an HTTP/1.1 origin server, and if the client sees the
   connection close before receiving any status from the server, the
   client SHOULD retry the request.

Can any Apache guru suggest some workaround?


"enzo" <> wrote in message
> I'm having a lot of difficulty in using MS' Web Publishing Wizard (WPW for
> short) to upload files to an Apache webserver with HTTP POST method. The
> basic problem seems to be that WPW sends a "Content-Length: 0" header,
> regardless of the actual file size; Apache apparently grabs this value and
> closes stdin immediately, preventing the CGI script from receiving the
> posted data. This is what WPW sends to the web server (captured with
> listening on the port 80):
> POST /iems/scripts/ HTTP/1.1
> Accept: */*
> Content-Type: Multipart/Form-Data,boundary=0041@18467#6334
> User-Agent: Microsoft HTTP Post (RFC1867)
> Host: localhost.localdomain
> Content-Length: 0
> Connection: Keep-Alive
> Cache-Control: no-cache
> This looks like a WPW bug. Has anybody found a workaround? Or is WPW
> supposed to work only with IIS?
> TIA --
> Enzo
> (

View raw message