[racket] Print Cookie Path issue

J G Cho wrote at 07/01/2011 03:27 PM:
> Looking at net/cookie-unit.rkt, it's not obvious to me why "" are being printed.
>   

Looks like "cookie-path", for one, can add the quotes (indirectly; 
ultimately in "convert-to-quoted").

Offhand, I could not tell you with certainty what the correct behavior 
should be in all cases.  I'm guessing that most likely this is a bug in 
the Racket library, but it could also be a quirk of interaction with the 
servers when the library is actually standards-compliant.

One suggestion I have is to temporarily ignore the RFCs and other 
specifications, start up Wireshark, pick a test case Web page that your 
Racket program doesn't like, see what HTTP popular Web browsers like 
Firefox and recent IE receive and send for that page, and then compare 
to what your Racket program receives and sends.  Sadly, the popular 
browsers are the overriding de facto standard here, not IETF and W3C 
standards and other documents.

I say "receive and send" because sometimes problems like these are due 
to servers sending headers differently depending on what HTTP client 
they think is in use, or depending on unusual headers they receive from 
the client.  The server isn't always doing this for great reasons: 
besides working around bugs in old IE versions with hacks, they might 
simply be falling through to a buggy code path that hardly anyone ever 
sees because you aren't doing something in your headers that all the 
popular browsers do.

If you're not up to Wiresharking, I can do it this weekend, if you send 
me a standalone file of Racket code and a URL to a Web page that 
together demonstrate the problem.

(BTW, there is a proprietary Racket library for HTTP headers, which one 
company developed, and which I'm hoping they can open source.  I don't 
know whether it would handle this particular case differently.  This is 
an anecdotal reminder that it can be easier to feed open source 
contributions back to a project continuously from the start, than to try 
to open source after the fact.  Open-sourcing after the fact can present 
more unknowns all at once, and can require lots of work and agreements 
among many parties.  So, try to have agreements in place from the start, 
as a matter of course, and move your general-purpose code to PLaneT and 
as Racket patches early and often, so the unknowns are resolved in small 
pieces.)

-- 
http://www.neilvandyke.org/