bug#21888: guix-publish gets ERROR when serve gtk+.

[Ludovic Courtès]

address@hidden (宋文武) skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> 宋文武 <address@hidden> skribis:
>>
>>> ---request begin---
>>> GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
>>> User-Agent: Wget/1.16.3 (linux-gnu)
>>> Accept: */*
>>> Accept-Encoding: identity
>>> Host: localhost:8080
>>> Connection: Keep-Alive
>>>
>>> ---request end---
>>>
>>> ---response begin---
>>> HTTP/1.1 404 Not Found
>>> Content-Length: 69
>>> Content-Type: text/plain;charset=utf-8
>>>
>>> ---response end---
>>> Registered socket 3 for persistent reuse.
>>> URI content encoding = 'utf-8'
>>> Skipping 69 bytes of body: [Resource not found: 
>>> /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
>>
>> Here ‘guix publish’ returns 404, presumably because
>> /gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
>> or not valid.
>>
>> Is this correct?
> No, the gtk+ item is valid, and replace 'gtk+' with 'gtk%2B' in the url
> will make wget download it happily.

‘guix publish’ correctly decodes URIs in ‘request-path-components’, but
‘uri-decode’ does this:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(web uri)
scheme@(guile-user)> (uri-decode "/gtk+")
$12 = "/gtk "
scheme@(guile-user)> (string-ref $12 4)
$13 = #\space
--8<---------------cut here---------------end--------------->8---

I think that ‘uri-decode’ is right, and that Wget is wrong when it fails
to replace ‘+’ with ‘%2B’.

Regardless, the problem is that the faulty /nar/…-gtk+ URI comes from a
.narinfo generated by ‘guix publish’ itself.  The fix is for ‘guix
publish’ to properly percent-encode it in the narinfo.

Done in 93961f02987cf738d116cc85cc32d97c2a488222.

Thanks,
Ludo’.