chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #1074: intarweb request parsing and Spiffy handli


From: Chicken Trac
Subject: Re: [Chicken-janitors] #1074: intarweb request parsing and Spiffy handling of said requests is inconsistent in case of improper request line URIs
Date: Sun, 24 Nov 2013 13:02:45 -0000

#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:  closed                
  Priority:  major    |   Milestone:  someday               
 Component:  unknown  |     Version:  4.8.x                 
Resolution:  fixed    |    Keywords:  bad-request connection
----------------------+-----------------------------------------------------
Changes (by sjamaan):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:12 RvdH]:
 > Modern browsers nowadays don't send bogus requests. But the point is:
 not all clients are browsers.

 That's exactly the problem.  You can't assume a well-behaved client.  The
 worst kind of "people" are on the internet, actively trying to abuse
 software which does assumes all clients play by the rules.

 > Actually, more and more of the clients are non-browsers.
 >
 > If you develop web services (i.e. server-to-server communication), it a
 extremely useful to have a web server that sends you correct status codes
 back, so you know what you did wrong as a developer.

 I understand this.  However, if a developer is exceeding request limits,
 he's doing something Very Wrong.  Again, they can always contact the admin
 and ask what went wrong. Then the admin can decide whether to trust this
 person or not.

 > That's why (claiming to be an HTTP server) it matters what you send back
 and that's why it matters that you adhere to the HTTP standard.

 But in this case it's the client who isn't adhering to that same standard:
 they're not even sending HTTP/1.x requests!  So your logic is upside-down;
 these requests fall outside the spec, and the spec does not say anything
 about what to do with non-HTTP requests. We are still conforming to the
 RFC when we reject these requests as being non-HTTP by disconnecting.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]