| Message ID | 20201024144929.4529-1-ludo@gnu.org |
|---|---|
| Headers | show |
| Series | 'guix publish --cache' can publish items not yet cached | expand |
Hi! Just one general comment about this issue: Ludovic Courtès <ludo@gnu.org> writes: > Thus, the first narinfo request for an item would always return 404; > one would have to wait until the item is baked to get 200 and download > the substitute. I'd argue that returning unconditionally the 404 is a problem. If the nar is getting baked, I guess that a 202[1] would be the appropriate answer, and I'd leave the 404 for invalid store paths[2]. This way the client could implement more policies: the classic timeout, but also, for example, it might check other servers before checking once again if nobody else has it, or directly wait until a 404 is reached. WDYT? Happy hacking! Miguel [1] Section 10.2.3 from https://www.ietf.org/rfc/rfc2616.txt [2] I understand that it isn't at all a bad usage of the 404, as it explicitly says that the condition might be temporary, but on the other hand I don't know how could that extra information be used by a rogue client in any way worse than it could do right now, as the server process is doing the same computation more or less in both cases.
Hi! Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: > Ludovic Courtès <ludo@gnu.org> writes: >> Thus, the first narinfo request for an item would always return 404; >> one would have to wait until the item is baked to get 200 and download >> the substitute. > > I'd argue that returning unconditionally the 404 is a problem. If the > nar is getting baked, I guess that a 202[1] would be the appropriate > answer, and I'd leave the 404 for invalid store paths[2]. This way the > client could implement more policies: the classic timeout, but also, for > example, it might check other servers before checking once again if > nobody else has it, or directly wait until a 404 is reached. WDYT? Indeed, 202 seems more appropriate (and it’s precisely half of 404, that tells something!). Unfortunately (guix scripts substitute) currently explicitly checks for 404 and 200 and considers anything else to be a transient error with a default TTL (in ‘handle-narinfo-response’). So we would need to adapt that first and then wait until some time has passed before ‘guix publish’ can return 202. :-/ I guess we can change (guix scripts substitute) with that in mind already. WDYT? Ludo’.
Hi, Ludo! Ludovic Courtès <ludo@gnu.org> writes: > Hi! > > Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: > >> Ludovic Courtès <ludo@gnu.org> writes: >>> Thus, the first narinfo request for an item would always return 404; >>> one would have to wait until the item is baked to get 200 and download >>> the substitute. >> >> I'd argue that returning unconditionally the 404 is a problem. If the >> nar is getting baked, I guess that a 202[1] would be the appropriate >> answer, and I'd leave the 404 for invalid store paths[2]. This way the >> client could implement more policies: the classic timeout, but also, for >> example, it might check other servers before checking once again if >> nobody else has it, or directly wait until a 404 is reached. WDYT? > > Indeed, 202 seems more appropriate (and it’s precisely half of 404, that > tells something!). :-) > Unfortunately (guix scripts substitute) currently explicitly checks for > 404 and 200 and considers anything else to be a transient error with a > default TTL (in ‘handle-narinfo-response’). So we would need to adapt > that first and then wait until some time has passed before ‘guix > publish’ can return 202. :-/ I see, it uses 'max-age from the http response only when it's a 404. Nonetheless, correct me if I'm wrong, the difference is 5 vs 10 minutes, so I don't think we should wait too much to upgrade both sides. :-) > I guess we can change (guix scripts substitute) with that in mind > already. WDYT? I fully agree with that. Adding 202 together with 404 would be enough as an start, wouldn't it? -------------------------------8<----------------------------- (cache-narinfo! url (hash-part->path hash-part) #f (if (or (= 404 code) (= 202 code)) ttl %narinfo-transient-error-ttl)) ------------------------------->8----------------------------- Happy hacking! Miguel
Hi, Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: > I fully agree with that. Adding 202 together with 404 would be enough > as an start, wouldn't it? > -------------------------------8<----------------------------- > (cache-narinfo! url (hash-part->path hash-part) #f > (if (or (= 404 code) (= 202 code)) > ttl > %narinfo-transient-error-ttl)) > ------------------------------->8----------------------------- Yes, exactly! Ludo’.
Hi, Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: > >> I fully agree with that. Adding 202 together with 404 would be enough >> as an start, wouldn't it? >> -------------------------------8<----------------------------- >> (cache-narinfo! url (hash-part->path hash-part) #f >> (if (or (= 404 code) (= 202 code)) >> ttl >> %narinfo-transient-error-ttl)) >> ------------------------------->8----------------------------- > > Yes, exactly! Should I, or you, push this before the release? It's probably worth having it already for 1.2. The optimization could be cool too: IIUC could be only the other if branch the one returning the 202 when it's widely accepted, perhaps I should have explicitly pointed out that earlier instead of driving too much the conversation to the return code, sorry for that. :-( Happy hacking! Miguel
Hi, Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: > Ludovic Courtès <ludo@gnu.org> writes: >> Hi, >> >> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis: >> >>> I fully agree with that. Adding 202 together with 404 would be enough >>> as an start, wouldn't it? >>> -------------------------------8<----------------------------- >>> (cache-narinfo! url (hash-part->path hash-part) #f >>> (if (or (= 404 code) (= 202 code)) >>> ttl >>> %narinfo-transient-error-ttl)) >>> ------------------------------->8----------------------------- >> >> Yes, exactly! > > Should I, or you, push this before the release? It's probably worth > having it already for 1.2. Agreed, you can go ahead and push this change. > The optimization could be cool too: IIUC could be only the other if > branch the one returning the 202 when it's widely accepted, perhaps I > should have explicitly pointed out that earlier instead of driving too > much the conversation to the return code, sorry for that. :-( No problem! Ludo’.