[drakma-devel] Lenient read-line*
I've attached a small patch which makes chunga:read-line* a little more lenient with regards to line endings. Currently (drakma:http-request "http://news.ycombinator.com") fails with an EOF since the arc server doesn't respond with CRLF but only uses plain LF. The attached patch works around this by assuming that when a LineFeed is encountered it also designates the end of a line, although it is quite possibly the wrong thing. Cheers, Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
On Thu, 26 Apr 2007 15:16:18 +0100, Sean <rosssd@gmail.com> wrote:
I've attached a small patch which makes chunga:read-line* a little more lenient with regards to line endings.
Currently (drakma:http-request "http://news.ycombinator.com") fails with an EOF since the arc server doesn't respond with CRLF but only uses plain LF.
So much for Arc...
The attached patch works around this by assuming that when a LineFeed is encountered it also designates the end of a line, although it is quite possibly the wrong thing.
Thanks, but I wouldn't want to accept that in this form. I think this liberal behaviour should be controlled by a user-visible variable and the default should be to stick to the RFC. Also, when sending patches, please adhere to the coding style of the rest of the code: http://weitz.de/patches.html Thanks, Edi.
On Thu, 2007-04-26 at 16:24 +0200, Edi Weitz wrote:
On Thu, 26 Apr 2007 15:16:18 +0100, Sean <rosssd@gmail.com> wrote:
I've attached a small patch which makes chunga:read-line* a little more lenient with regards to line endings.
Currently (drakma:http-request "http://news.ycombinator.com") fails with an EOF since the arc server doesn't respond with CRLF but only uses plain LF.
So much for Arc...
Sean, i hope you filed a bug against arc - this isn't valid HTTP any more.
The attached patch works around this by assuming that when a LineFeed is encountered it also designates the end of a line, although it is quite possibly the wrong thing.
Thanks, but I wouldn't want to accept that in this form. I think this liberal behaviour should be controlled by a user-visible variable and the default should be to stick to the RFC.
Yes, please. I'd like to know when i get invalid responses. And once you start accepting stray LF you might want to accept stray CR as well - the road to insanity ;-) I vaguely recall sever performance problems in the early days of Java exactly _because_ their network stack tried some clever heuristics to catch these kinds of errors. Cheers Ralf Mattes P.S: Once again, thank you so much Edi. I'm just testing some custom Apache modules with Drakma. It's such a pleasure to be able to create requests from the repl.
Also, when sending patches, please adhere to the coding style of the rest of the code:
Thanks, Edi. _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
On Thu, 2007-04-26 at 16:24 +0200, Edi Weitz wrote:
So much for Arc...
and hopes where so high....
Thanks, but I wouldn't want to accept that in this form. I think this liberal behaviour should be controlled by a user-visible variable and the default should be to stick to the RFC.
Sounds good, if you are happy with an exported variable named *linefeed-is-crlf* I'll put together a patch which conditionally enables the aforementioned behaviour (and updated documentation). Cheers, Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
On Thu, 26 Apr 2007 16:07:50 +0100, Sean <rosssd@gmail.com> wrote:
Sounds good, if you are happy with an exported variable named *linefeed-is-crlf* I'll put together a patch which conditionally enables the aforementioned behaviour (and updated documentation).
Yes, that's fine. But maybe we should pick up Ralf's suggestion (hehe... :) to also accept stray CRs while we're at it. Then the name should probably be something like *ACCEPT-WRONG-LINE-ENDINGS-P*. Feel free to pick a better name, you're the native speaker... :)
Edi Weitz wrote:
On Thu, 26 Apr 2007 16:07:50 +0100, Sean <rosssd@gmail.com> wrote:
Sounds good, if you are happy with an exported variable named *linefeed-is-crlf* I'll put together a patch which conditionally enables the aforementioned behaviour (and updated documentation).
Yes, that's fine.
But maybe we should pick up Ralf's suggestion (hehe... :) to also accept stray CRs while we're at it. Then the name should probably be something like *ACCEPT-WRONG-LINE-ENDINGS-P*. Feel free to pick a better name, you're the native speaker... :)
Might I suggest *ACCEPT-BOGUS-EOLS* ? --Jeff
Sorry for the delay. I've attached a patch which implements *accept-bogus-eols* for read-line* along with updated docs. When bound to a non-nil value then a lone CR or LF will be accepted as EOL. Cheers, Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
On Fri, 2007-04-27 at 13:24 +0100, Sean wrote:
Sorry for the delay.
I've attached a patch which implements *accept-bogus-eols* for read-line* along with updated docs. When bound to a non-nil value then a lone CR or LF will be accepted as EOL.
Ok, since even Edi took my remark (partly) serious I'll bite: Could you please define "lone" in this context? Cheers, RalfD
Cheers, Sean.
_______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
On Fri, 2007-04-27 at 19:50 +0200, Ralf Mattes wrote:
On Fri, 2007-04-27 at 13:24 +0100, Sean wrote: Ok, since even Edi took my remark (partly) serious I'll bite:
Could you please define "lone" in this context?
OK, A single LF, or a single CR (which may or may not be followed by a LF), will constitute an EOL. Cheers, Sean (who is finally back in front of a PC). -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
Scribit Sean dies 30/04/2007 hora 12:08:
A single LF, or a single CR (which may or may not be followed by a LF), will constitute an EOL.
How should a sequence of CRs and LFs be interpreted? Should "<CR><LF><LF>" be three or two EOL? Curiously, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
On Mon, 2007-04-30 at 13:35 +0200, Pierre THIERRY wrote:
Scribit Sean dies 30/04/2007 hora 12:08:
A single LF, or a single CR (which may or may not be followed by a LF), will constitute an EOL.
How should a sequence of CRs and LFs be interpreted?
Should "<CR><LF><LF>" be three or two EOL?
This would be 2, A CRLF and a LF. Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
Scribit Sean dies 30/04/2007 hora 13:01:
Should "<CR><LF><LF>" be three or two EOL? This would be 2, A CRLF and a LF.
So a CR is an EOL if not followed by a LF, a LF is an EOL if not following a CR, a CR or LF are an EOL in all other cases and a CRLF is an EOL. Is that right? Curiously, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
On Mon, 2007-04-30 at 14:08 +0200, Pierre THIERRY wrote:
Scribit Sean dies 30/04/2007 hora 13:01:
Should "<CR><LF><LF>" be three or two EOL? This would be 2, A CRLF and a LF.
So a CR is an EOL if not followed by a LF, a LF is an EOL if not following a CR, a CR or LF are an EOL in all other cases and a CRLF is an EOL. Is that right?
Yes :) Amused, Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.
On Fri, 27 Apr 2007 13:24:23 +0100, Sean <rosssd@gmail.com> wrote:
Sorry for the delay.
And sorry for my delay as well... :)
I've attached a patch which implements *accept-bogus-eols* for read-line* along with updated docs. When bound to a non-nil value then a lone CR or LF will be accepted as EOL.
I've released 0.3.0 which incorporates your changes. Thanks, Edi.
participants (5)
-
Edi Weitz -
Jeff Cunningham -
Pierre THIERRY -
Ralf Mattes -
Sean