Re: [Chicken-janitors] #1074: uri-generic: percent-encodings in the authority section cause problems

[Chicken Trac]

#1074: uri-generic: percent-encodings in the authority section cause problems
----------------------+-----------------------------------------------------
  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 sjamaan):

 I've fixed the one problem in uri-generic (trunk), but I'm unsure how to
 proceed now.

 Spiffy still disconnects when receiving 3 of the 5 headers after this
 patch. The reason is, like I said, the browser is generating invalid URIs.
 (the {{{/%20/}}} case is a valid URI reference, it's just not a valid
 reference type to use in this context; all the others really cause the
 browser to produce invalid URI syntax like {{{/%}}}, {{{/%%22}}} and
 {{{//%%20/}}})

 The problem is, the HTTP protocol to use is determined from the request
 line. However, the request line '''itself''' can't even be properly parsed
 (because the URI cannot be parsed), so we're properly speaking not even
 using the protocol, so we can't signal an in-protocol error (400 bad
 request).

 I COULD change the intarweb code to try to parse, say {{{METHOD [random
 cruft] HTTP/1.0}}} to a request object with no URI, and let spiffy detect
 this and return a 400 (since obviously the client is '''trying''' to speak
 HTTP/1.0; it just fails to send a 100% correct request line).  However,
 strictly speaking that's not correct, and all code that uses intarweb will
 now need to be able to detect this invalid half-parsed state with an
 incomplete object being returned.

 If I don't change it to do that, for consistency I probably should change
 it to reject the invalid URIs outright by refusing to recognise these URIs
 on the request line, so all the examples above produce a disconnection.

 I'm really sitting on the fence here. Both options seem problematic: the
 one is incorrect (sending a HTTP response of "400 bad request" on what is
 essentially a non-HTTP request), and the other is just unfriendly
 (abruptly disconnecting when receiving a 99% correct "HTTP request").
 What do you think?

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