Building your own URL only works for GET requests, not for POST requests. I don't need to stop drakma from encoding query strings for my application, I can pass it the string with spaces and let it encode them to plus signs. I'm suggesting a useful, minor, upward-compatible addition to drakma's API. Perhaps drakma's interface is too high-level for the kind of application that might need more direct control of encoding and decoding. I can understand not wanting to add another keyword to http-request and another few lines to the documentation. That's your judgement call. Trivial-http and cl-curl are also available. Anyway, thanks for listening, and thanks for the code... ----- Original Message ---- From: Edi Weitz <edi@agharta.de> To: General interest list for Drakma and Chunga <drakma-devel@common-lisp.net> Sent: Monday, July 7, 2008 9:41:29 AM Subject: Re: [drakma-devel] Bug report: Overeager encoding of parameters On Mon, 7 Jul 2008 09:08:18 -0700 (PDT), Eric Benson <eric_a_benson@yahoo.com> wrote:

RFC 2396 has been superseded by RFC 3986, although that does not affect this case.

RFC 2396 is what is quoted in RFC 2616, so that's why I was referring to it.

http://www.w3.org/Addressing/URL/4_URI_Recommentations.html

"Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded.

That's what Drakma does.

For the record, neither IE nor Firefox encodes plus signs when they are entered as part of the query.

They encode them if they are GET parameters, like Drakma. Open the attached HTML page in IE or Firefox and enter "a+b", then press the Return key.

It seems to me that http-request should make encoding of the parameters optional, since a client program may need to deal with encoded as well as unencoded strings. Otherwise, a caller of http-request that already has encoded parameters must explicitly decode them before calling.

No, you are free to build the URL for Drakma yourself. Edi. -----Inline Attachment Follows-----