Respect the "Content-Length" header when parsing form data.

[phmarek]

This is a plain bugfix.

Another (related) point is a (potential) client bug as well, but we might want to fix that in hunchentoot:
When trying to upload a file that you don't have access rights for, firefox happily goes ahead and sends a request with "Content-length: 0" and some mime boundary header but then no actual post data (as there's no content to send), resulting in (with the patch above) an EOF error.
(Without the patch, the server thread runs into a TCP timeout, as it waits for the never-sent mime boundary.)

end of file on #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}>
   [Condition of type END-OF-FILE]

Frames:
  0.  (READ-CHAR #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}> T NIL #<unused argument>)
  1.  ((FLET RFC2388::RUN :IN RFC2388::READ-UNTIL-NEXT-BOUNDARY) #<BROADCAST-STREAM {10000321A3}>)
  2.  (RFC2388::READ-UNTIL-NEXT-BOUNDARY #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}> "---------------------------129268202915739752981342792626" T NIL)
  3.  ((:METHOD RFC2388:PARSE-MIME (STREAM T)) #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}> "---------------------------129268202915739752981342792626" :WRITE-CONTENT-TO-FILE T) [fast-method]
  4.  ((SB-PCL::EMF RFC2388:PARSE-MIME) #<unused argument> #<unused argument> #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}> "---------------------------129268202915739752981342792626")
  5.  (HUNCHENTOOT::PARSE-RFC2388-FORM-DATA #<FLEXI-STREAMS:FLEXI-IO-STREAM {100BF9FC23}> "multipart/form-data; boundary=---------------------------129268202915739752981342792626" #<FLEXI-STREAMS::FLEXI-UTF..
  6.  ((FLET "FORM-FUN-4" :IN HUNCHENTOOT::PARSE-MULTIPART-FORM-DATA))
  7.  (HUNCHENTOOT::PARSE-MULTIPART-FORM-DATA #<HUNCHENTOOT:REQUEST {100BF9C0B3}> #<FLEXI-STREAMS::FLEXI-UTF-8-FORMAT (:UTF-8 :EOL-STYLE :LF) {10034A0AC3}>)
  8.  ((FLET "FORM-FUN-7" :IN HUNCHENTOOT::MAYBE-READ-POST-PARAMETERS))
  9.  (HUNCHENTOOT::MAYBE-READ-POST-PARAMETERS :REQUEST #<HUNCHENTOOT:REQUEST {100BF9C0B3}> :FORCE T :EXTERNAL-FORMAT NIL)
  10. ((:METHOD HUNCHENTOOT:POST-PARAMETERS :BEFORE (HUNCHENTOOT:REQUEST)) #<HUNCHENTOOT:REQUEST {100BF9C0B3}>) [fast-method]
  11. ((SB-PCL::EMF HUNCHENTOOT:POST-PARAMETERS) #<unused argument> #<unused argument> #<HUNCHENTOOT:REQUEST {100BF9C0B3}>)
  12. (HUNCHENTOOT:POST-PARAMETER "file" #<HUNCHENTOOT:REQUEST {100BF9C0B3}>)

I'm not sure about the correct way to handle that --

• should we just fail the complete request at some higher level (is "Content-length: 0" invalid?),
• should we fail only when arguments are being requested (as it seems to be now), or
• should we return NIL for this parameter only (as this parameter was never sent) and not fail?

[stassats]

Other places that parse content-length use :junk-allowed t. And do you have a test-case that uses drakma?
And for the other issue, open a separate ticket.

[stassats]

And how come multipart/form-data has Content-Length?

[phmarek]

I guess it's some kind of bug in the user agent.

POST /upload-file HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8080/
Content-Type: multipart/form-data; boundary=---------------------------179550789421416635281736454007
Content-Length: 0
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Still, hunchentoot shouldn't hang with such input.

New issue is #165, thanks.

[phmarek]

Well, do we want to allow a header that should contain numeric data to contain trash as well?
I didn't specify :junk-allowed T on purpose, to make HT break at invalid input.

Well, here you are.