Re: [Chicken-janitors] #1074: intarweb request parsing and Spiffy handling of said requests is inconsistent in case of improper request line URIs

[Chicken Trac]

#1074: intarweb request parsing and  Spiffy handling of said requests is
inconsistent in case of improper request line URIs
----------------------+-----------------------------------------------------
  Reporter:  RvdH     |       Owner:  sjamaan               
      Type:  defect   |      Status:  new                   
  Priority:  major    |   Milestone:  someday               
 Component:  unknown  |     Version:  4.8.x                 
Resolution:           |    Keywords:  bad-request connection
----------------------+-----------------------------------------------------

Comment(by andyjpb):

 Replying to [comment:5 RvdH]:
 > First of all, I think the server should always respond with a status
 code. Disconnecting is (as you mentioned as well) not really nice.
 >
 > W3C says (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) the
 following on 400 Bad Request:
 >
 > {{{
 > The request could not be understood by the server due to malformed
 syntax. The client SHOULD NOT repeat the request without modifications.
 > }}}
 >
 > If the URI is not a URI, you could say it is malformed syntax, so
 returning a 400 is probably correct.
 >
 > If you do not like the idea of returning a 400, you could instead return
 a 500 (Internal Server Error) for every exception/error that appears
 during parsing.

 This is very much along the lines of my own thinking when I first read
 this ticket. However, we should strictly return a 4xx series error rather
 than a 5xx series error because the 4xx class is reserved for errors
 caused by the client and the 5xx class for errors caused by the server.
 Moreover, the W3C spec isn't too detailed on what to do with respect to
 ensuring synchronization between both sides when the connection is coming
 up, although it does talk a bit about what to do when it's going down:

 {{{
 If the client is sending data, a server implementation using TCP SHOULD be
 careful to ensure that the client acknowledges receipt of the packet(s)
 containing the response, before the server closes the input connection. If
 the client continues sending data to the server after the close, the
 server's TCP stack will send a reset packet to the client, which may erase
 the client's unacknowledged input buffers before they can be read and
 interpreted by the HTTP application.
 }}}

 The scenario outlined in this ticket is particularly tricky because the
 error occurs during the parsing of the very first line of the request and
 the result of that parsing is used to actually bring the HTTP connection
 itself up on top of the raw TCP connection.


 It appeals to common sense that we'd return a 400 error here because
 that's what we'd do if we had trouble decoding some other part of the URI:
 for example the query string. However, there are much wider security and
 connection stability concerns at stake in this particular instance. On
 balance, I think we should do the safest thing, rather than the most
 elegant or most useful thing.

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/1074#comment:7>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.