Re: [dev] quark can not send files with '+' in the name

From: Laslo Hunhold <dev_AT_frign.de>
Date: Thu, 10 Jan 2019 22:08:21 +0100

On Thu, 10 Jan 2019 23:27:12 +0300
Platon Ryzhikov <ihummer63_AT_yandex.ru> wrote:

Dear Platon,

> I tried to use quark as local server for pacman but it returns 404
> error for files with '+' in filename. I found the following lines in
> http.c (83-85):
>
> if (*s == '+') {
> dest[i] = ' ';
> }
>
> Why does it replace '+' sign with space?

nice find! The snippet from http.c you are pointing to is part of the
decode() function. It is called during the parsing of the HTTP header
and used to decode URL-encoded strings.

URL-encoding is when you replace reserved characters (as specified in
Subsection 2.2 of RFC 3986[0]) with percent encoding. Space then turns
into %20, + turns into %2B and so forth. The list of reserved
characters is

   : / ? # [ ] _AT_ ! $ & ' ( ) * + , ; =

and it's the client's task to properly percent encode such characters
if necessary.

Now with URLs it gets a bit more complicated, as it's so-called
"application/x-www-form-urlencoded" content. Here it is actually, as
far as I understand, allowed by the client to replace spaces with + and
as a "reserved" character, which is not percent-encoded, the server
knows it means space. If you want to transmit a literal '+', you need to
percent encode it as %2B. Still, other servers behave differently and
keep the +, and spaces are properly percent encoded as %20 by the
clients I've tested.

Thus, I have removed the plus-replacement[1], because it serves no
purpose from what I can tell and there's no mention of it in the
standards. Effectively, this also resolves your problem as well.

Thanks for reaching out and using quark! :)

With best regards

Laslo Hunhold

[0]:https://tools.ietf.org/html/rfc3986
[1]:https://git.suckless.org/quark/commit/e299e186edba03192fc12f6709df48d02aa83849.html

-- 
Laslo Hunhold <dev_AT_frign.de>

Received on Thu Jan 10 2019 - 22:08:21 CET

This archive was generated by hypermail 2.3.0 : Thu Jan 10 2019 - 22:12:07 CET