Comment:
> Hi there, we had a question here about your file upload
> specification. It does not seem to require a content-length for the
> POST data which is being sent to the server.
> In your compatibility section, you discuss implementation of this type
> of form handler via CGI. In order to work with servers other than NCSA
> httpd such as CERN httpd and Netsite, the browser must send
> content-length so the server knows how much data to pass on to the
> script. The CGI spec implicitly requires content-length in a POST
> request, and states that the server is only required to send that many
> bytes to the CGI program on stdin.
> There's some concern here that your test implementation does not send
> a content-length. Is this correct? If so, do you plan to make sure
> your CGI implementation will work with all of today's servers without
> modifying them to parse the multipart data?
My reply:
> I took content-length out of the proposal for the parts of
> multipart/form-data because of the strong concern of the MIME
> community that content-length has had serious problems.
> The HTTP spec notes that many implementations require content-length
> when there is a PUT or POST, but in this particular case, where the
> content-type of the POST is self-delimiting, the content-length should
> not be required. I suppose, under the spirit of 'be conservative in
> what you send' it would be better for a real implementation to include
> content-length, but I was worried about the case where the data in the
> files being uploaded might change between computation of
> content-length and the actual data transmission.
I intend to note this issue in the revised version of the file upload
draft, but I don't think the HTML part of the specification will
change.
================================================================
Comment:
> I had another concern as well. In your example:
> ----------------------------------------------------------
> The client would send back the following data:
> Content-type: multipart/form-data, boundary=AaB03x
> --AaB03x
> content-disposition: form-data; name="field1"
> Joe Blow
> --AaB03x
> content-disposition: form-data; name="pics"
> Content-type: multipart/mixed, boundary=BbC04y
> --BbC04y
> Content-disposition: attachment; filename="file1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> ... contents of file1.txt ...
> --BbC04y
> Content-disposition: attachment; filename="file2.gif"
> Content-type: image/gif
> Content-Transfer-Encoding: binary
> ...contents of file2.gif...
> --BbC04y--
> --AaB03x--
> -----------------------------------------------------------------
> Notice that your example excludes a double linefeed after
> the initial header block. This is not a legal MIME message.
> You must send a double linefeed to separate the first
> block of headers and the body of the message.
> Also you don't specify what to do in the case where only
> one file is sent. I assume it would look like this:
> --------------------------------------------------
> Content-type: multipart/form-data, boundary=AaB03x
> --AaB03x
> content-disposition: form-data; name="field1"
> Joe Blow
> --AaB03x
> content-disposition: form-data; name="pics"
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> --AaB03x--
> ---------------------------------------------------
> where "pics" was the name of the "file" input type.
This comment is (more or less) correct. The initial header block
requires two CRLFs (not just linefeeds) after the initial header
block. And an example where only one file is sent should be included
in the I-D.
If there are other comments on the file upload proposal, please send
them ASAP so that I can address them in the next version of the I-D.