This patch adds two things to web.client:
1) support for basic authentication. (but not digest authentication).
2) allow the delimiter to be changed from '\r\n' to '\n'. Because of bugs in browsers, all servers send '\r\n' instead of the technically legal '\n'. But that's a pain for nph-sh scripts, so here's a quick hack to change the delimiter. To be legal, HttpClient should handle both '\n' and '\r\n' simultaneously, but LineReceiver does not provide this facility, so I'm using this hack instead.
Bryan
On May 11, 2004, at 4:11 PM, Bryan Larsen wrote:
- allow the delimiter to be changed from '\r\n' to '\n'. Because of
bugs in browsers, all servers send '\r\n' instead of the technically legal '\n'. But that's a pain for nph-sh scripts, so here's a quick hack to change the delimiter. To be legal, HttpClient should handle both '\n' and '\r\n' simultaneously, but LineReceiver does not provide this facility, so I'm using this hack instead.
Excuuuuuse me? HTTP *requires* CRLF to terminate header lines. "\n" is never ever ever a legal header delimiter! The last bit of the HTTP 1.1 spec, under 19.3 "Tolerant Applications", does allow you to interpret incoming \n as an end of line: "The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR."
But that's not even a SHOULD, it's just a "we recommend", so I think it ought to be ignored. Anyone broken enough to send \n deserves what's coming to them.
James
Excuuuuuse me? HTTP *requires* CRLF to terminate header lines. "\n" is never ever ever a legal header delimiter!
I feel appropriately chastened. even old HTTP 0.9 required crlf.
The CGI spec allows lf or crlf. HTTP doesn't.
sorry,
Bryan
-
Bryan Larsen -
James Y Knight