patch: multiple-line http headers (and a free bonus Content-Type msg change)
Finally got around to it. Since it's another one of those things I am probably never going to encounter in the outside world, I tested by sticking whitespace into headers sent by file.c. PS I see that this guy has a rant about how the headers can attain an arbitrary degree of horribleness if you really want to go by the letter of the rfc: http://www.and.org/texts/server-http
Hi, On Tue, Jan 08, 2008 at 08:01:50PM +0000, place wrote:
Finally got around to it.
Since it's another one of those things I am probably never going to encounter in the outside world, I tested by sticking whitespace into headers sent by file.c.
OK, committed with some minor comments.
PS I see that this guy has a rant about how the headers can attain an arbitrary degree of horribleness if you really want to go by the letter of the rfc: http://www.and.org/texts/server-http
Welcome to the RFC world! :-) Sometimes RFCs provide good advice, others, they constitute an antology example of what Porter called "rising the entry barriers". If a certain market has a low-cost entrance for potential competitors, the existing ones may arrange for an artificial obstacle to rise the entry barriers. e.g. SW companies may get a few employees inside an RFC committee to get sure the protocol gets overly complex so it takes a huge effort to comply. I do consider HTTP-1.1 and the SGML spec of HTML (which not even the bigger browsers do comply with), as excellent examples of this. *Sigh*, every now and then I reflect how much easier it would be if clean-room, vested-interest-free RFCs were produced. Some RFCs are very helpful though (as the one for URL/URIs and resolving algorithms). This is very good news because it demonstrates that good, simple and clean RFCs can be produced in the real world. In what regards to us as a project, we try to comply with the advice in good RFCs, ignore the bloat and artificial barriers, and to try to implement an eclectic subset of it. -- Cheers Jorge.- PS: A good article on how to destroy a protocol was given by Raph Levien here: http://www.levien.com/free/decommoditizing.html
Jorge wrote:
In what regards to us as a project, we try to comply with the advice in good RFCs, ignore the bloat and artificial barriers, and to try to implement an eclectic subset of it.
Oh, okay. I'd been under the impression that dillo leaned very strongly toward spec-following. But "don't follow a stupid rule if it's extra work" sounds eminently reasonable.
participants (2)
-
jcid@dillo.org
-
place@gobigwest.com