search

arclanguage / anarki

Community-managed fork of the Arc dialect of Lisp; for commit privileges submit a pull request.
http://arclanguage.github.io
Other
1.17k stars 160 forks source link

case-sensitive field header matching in parseheader #2

Closed jazzyb closed 11 years ago

jazzyb commented 14 years ago

I noticed a bug when I tried to login to Hackernews with the Lynx web browser. My browser sent the following POST request:

""" POST /y HTTP/1.1 Host: news.ycombinator.com [snip] Content-length: 37

fnid=blah&u=jazzyb&p=**** """

The server returned the error message, "Post request without Content-Length."

Doing some diving into the code I discovered that the content-length value is grabbed from the header in file srv.arc, function parseheader with a line that matches against the string "Content-Length:". This is a case-sensitive match (notice the lower case "length" in the POST request), but the HTTP RFC (rfc2616 sec. 4.2) states that field headers should be case-insensitive.

I've recompiled my Lynx browser so that my client sends the server what it wants, but I thought I would mention the non-standard behavior. I recommend that all field header string matches in the server code be changed to case-insensitive matches.

EugenDueck commented 11 years ago

Not sure if news.ycombinator is running this fix, but if it does, it does not work. Maybe that's due to http.arc still be broken:

(alref req!hds "Content-Length")

I don't know any arc, but a brief check at http://ycombinator.com/arc/tut.txt:

The function alref returns the first value corresponding to a key in an alist:

arc> (alref codes "Boston") bos

gives me the feeling this is case-sensitive.

akkartik commented 11 years ago

I'm pretty sure that bugfixes here don't get picked up on HN :(

I think the code you mentioned is ok because all headers pass through normalize-hdname: http://github.com/nex3/arc/blob/2978053e45/lib/http.arc#L39

Feel free to reopen if I'm missing something. (I should be a lot more responsive now.)