I'm new to this framework and web development in general: I ran across this problem today, and I think it's a bug (and I kinda fixed it), but I'm not sure...
Anyway, using Laszlo as a front-end, I tried to post to a url served by tbnl. Couldn't get at the POST data, couldn't get at it, couldn't get at it. Finally, I noticed two things:
1) the header from laszlo for content-type was: "application/x-www-form-urlencoded;charset=UTF-8" 2) in initialize-instance and recompute-request-parameters, the code was:
(string-equal "application/x-www-form-urlencoded" (string-assoc "content-type" headers-in))
So I tossed in:
(string-equal "application/x-www-form-urlencoded" (string-assoc "content-type" headers-in) :end2 (length "application/x-www-form-urlencoded))
which is not particularly efficient, but is at least correct.
Am I wrong?
On Fri, 12 May 2006 01:21:21 -0400, "John Bates" jwhbates@gmail.com wrote:
- the header from laszlo for content-type was:
"application/x-www-form-urlencoded;charset=UTF-8"
Thanks for the report. I've uploaded a new version (untested) which should fix this. It's kind of a workaround because actually for both content types TBNL should do the right thing immediately if the charset is explicitely specified. But that would involve a major change and including something like FLEXI-STREAMS and I don't have the time for that now.
Am I wrong?
No, your fix looked OK. You didn't notice STARTS-WITH-P, though.
Cheers, Edi.
John Bates wrote:
the header from laszlo for content-type was: "application/x-www-form-urlencoded;charset=UTF-8"
FYI, according to RFC 2616 HTTP/1.1, what follows Content-Type is:
type "/" subtype *( ";" attribute "=" value )
So if TBNL can't parse that, I's say it's a bug. They also seem to say that compliant HTTP/1.1 software should treat a missing charset parameter as ISO-8859-1, but I'm not sure.
Toby
-
Edi Weitz -
John Bates -
Toby