[drakma-devel] drakma and non-ASCII content

[Austin Haas]

You can also explicitly supply the value of the content-length as a
keyword argument to http-request. I use a wrapper that adds this:

  :content-length (if content
                      (babel:string-size-in-octets content :encoding :utf-8)
                      0)

I agree, though, that the default behavior can be surprising. It has
bitten me, too, and I've seen at least one other library built-on
Drakma that didn't account for it, either.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Fri Mar 09 10:24 , Robert Brown wrote:
> A co-worker of mine had some problems today using Drakma to POST a STRING
> containing non-ASCII characters encoded as UTF-8.  He was doing something
> equivalent to:
> 
> (http-request "http://zappa.com/favicon.ico"
>               :method :post
>               :content (concatenate 'string
>                                     "hello" (string #\white_square) "world")
>               :external-format-out :utf-8)
> 
> which ends up setting the Content-Length header value to 11, which is the
> LENGTH in characters of the string being sent.
> 
> The documentation says that "if content is a sequence, Drakma will use LENGTH
> to determine its length and will use the result for the 'Content-Length' header
> sent to the server," so Drakma is working as documented.
> 
> Also, I think I understand why this behavior is the default.  You don't want to
> scan a content string in order to determine what its length will be in octets
> once it has been encoded.  My co-worker could have used a vector of type
> (unsigned-byte 8) to hold his UTF-8 encoded data.
> 
> However, I think the current Drakma behavior may be a mistake.  People who want
> high performance are probably manipulating encoded strings as vectors of
> (unsigned-byte 8).  It's the casual users, those sending strings, who are the
> ones most likely to be bitten by the default behavior, but only when their
> strings contain non-ASCII characters.
> 
> bob
> 
> _______________________________________________
> drakma-devel mailing list
> drakma-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>