iyzs...@member.fsf.org (宋文武) skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> 宋文武 <iyzs...@openmailbox.org> 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’.
