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:

http://weitz.de/patches.html

Thanks, Edi. _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel

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... :)

On Thu, 26 Apr 2007 17:42:45 -0700, Jeff Cunningham jeffrey@cunningham.net wrote:

Might I suggest *ACCEPT-BOGUS-EOLS* ?

Yes, I like that.

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

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

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

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.