[Lispweb] Body parsing

[Brian Rice]

You should probably pass this and the other recent patch directly to 
Dan Barlow, as he is the author and (hopefully) maintainer of Araneida.

On Apr 13, 2005, at 2:06 PM, Richard Newman wrote:

> Hello list,
>   I'm not convinced that this sent the first time around, so 9 days 
> later I'm going to give it another shot.
>
>   The Araneida _request_ class has a body for POST requests. 
> _read-request-from-stream_ parses the HTTP body into an assoc list 
> with the following line (line 27, daemon.lisp):
>
> (parsed-body (if body (parse-body body '(#\&) len) nil))
>
>   This is perfectly sane behaviour for x-www-form-urlencoded POST 
> bodies (e.g. first=value&second=value). However, for all other bodies 
> it is destructive and nonsensical (particularly XML, which uses =). 
> Unfortunately, I'm working with those other bodies -- e.g. 
> application/rdf+xml.
>
>   My initial hack was to put in a simple test on the Content-Type 
> header:
>
> (parsed-body (if body
>                 ;; Use member on the raw assoc list to make sure we 
> catch requests
>                 ;; with multiple Content-Types.
> 			  (if (member "application/x-www-form-urlencoded"
> 				      (cdr (assoc :content-type headers)) :test #'string=)
> 			    (parse-body body '(#\&) len)
> 			    body)
> 			  nil))
>
>   i.e. only parse the body if we have form-encoded data; otherwise 
> just use the body string (one could also url-unencode the body 
> string). This split has the unfortunate side effect that for some 
> requests _(request-body request)_ will return an assoc list, and 
> sometimes a string. I don't know what consequences this would have on 
> existing code. _(stringp)_ is one remedy; another would be to provide 
> _body-data_ and _body-parsed_ (or similar names) slots on _request_, 
> rather than just _body_. I would think that if Araneida-based 
> applications are using the parsed data (and it's valid/correct) then 
> their clients must be sending the correct headers (e.g. wget sends 
> x-www-form-urlencoded by default), so putting this check in wouldn't 
> break anything, but I might be wrong.
>
>   Any thoughts, anyone?
>
>   Regards,
> -Richard
> http://www.holygoat.co.uk/blog
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/