buildkit: ADD from url fails with 'invalid not-modified ETag'
Build fails at:
ADD https://getcomposer.org/composer.phar /usr/local/bin/composer
Log:
=> [1/17] FROM docker.io/library/php:7.3-fpm@sha256:cf8e94d24d94329f13bcd430ae586f80278247e1c43e5f8b3d52c4ab16d2464f 0.0s
=> ERROR https://getcomposer.org/composer.phar 0.3s
=> [internal] load build context 0.0s
------
> https://getcomposer.org/composer.phar:
------
invalid not-modified ETag: "5c912760-1d3e0e"
I’m wondering if this is related to https://github.com/moby/buildkit/pull/835 but thought worth reporting so it can also be tested.
The etag seems to work just fine, i.e. curl -I -H 'if-none-match: "5c912760-1d3e0e"' https://getcomposer.org/composer.phar returns 304.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 18 (5 by maintainers)
Commits related to this issue
- http: Handle missing but unambiguous ETags in response If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed desc... — committed to rwe/buildkit by rwe 5 years ago
- http: Handle missing but unambiguous ETags in response If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed desc... — committed to rwe/buildkit by rwe 5 years ago
- http: Handle missing but unambiguous ETags in response If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed desc... — committed to tonistiigi/buildkit by rwe 5 years ago
- bump buildkit v0.6.2 full diff: https://github.com/moby/buildkit/compare/f7042823e340d38d1746aa675b83d1aca431cee3...ae10b292fefb00e0fbf9fecd1419c5f252e58895 fixes: - moby/buildkit#1144 Fix socket h... — committed to thaJeztah/docker by thaJeztah 5 years ago
- Avoid caching jaas-dashboard clone The jaas-dashboard clone was being cached in subsequent builds, so we weren't pulling in the latest version of the repo for every build. This should fix that. @jkf... — committed to nottrobin/jaas.ai by nottrobin 4 years ago
I’m also still having this issue (with the same exact URL) with docker 20.10.5
Which version is this supposed to have been fixed in?
please be aware that ADD is eveluated on every build and will not use cache in case the resource has change while a RUN curl will cache the result once and use the build cache from that point on. So using RUN and curl is not a full replcaement here
I believe I understand the cause.
The fix should be very simple ~, however I’m not set up for building in this ecosystem. Hopefully someone can provide a patch~ . EDIT see (untested) PR #1159.
I was seeing this too with a Google Cloud Storage URL and so decided to investigate. It seems unlikely that both GitHub releases and Google Cloud Storage are “misbehaving” with respect to ETags, and it’s likely that instead BuildKit may be misinterpreting the
If-None-Matchspec.Background info
Docker version info
Docker for Mac 2.1.1.0 (27260)Reproduction Steps
DockerfileThe first run (or a run after the cache is cleared) succeeds:
Running the same command again:
Clearing the cache with
docker builder pruneresets the state.Cause
If a single ETag is requested in
If-None-Match, the server may not include that (unambiguous) ETag header in the response.Detailed demonstration
Requesting the file directly:
Response headers. Notice the ETag.
Requesting the file
If-None-Matchwith that ETag:Notice that the ETag is not included in the response headers.
Requesting the file with multiple ETags in
If-None-Match:Now the ETag is included to disambiguate.
Fix
The following lines of code should be updated so that, if only one ETag was requested, and no ETag header was returned in the response, the requested ETag is assumed:
The error is produced by code that we use from BuildKit; in this part of the BuildKit code; https://github.com/moby/buildkit/blob/efc63357b84c844d72d68e017dcdbe8741122380/source/http/httpsource.go#L214-L226
I’m not sure if it’s an issue with the code, or if it’s an issue with the server from which you’re downloading though. I’m not very familiar with that part of the BuildKit code, but from looking at the code, it seems that it’s producing that error if BuildKit previously downloaded that URL (and stored the ETag), and when checking if the URL is still current (or if the cache can be used), it got a 304 “StatusNotModified” status from the server, but the server actually replied with a different ETag (in other words; the server responds that the content wasn’t modified, but the ETag indicates that it was)?
Still happening with Docker 20.10.18. No OAuth or authentication is involved:
The original issue was fixed two years ago; if you encounter this, and have more details, please use https://github.com/moby/buildkit/issues/2420 instead.
I’m also still having this issue with docker 20.10.8
I was getting this issue, but I found doing a
docker system prunemeant that I could rebuild again. Maybe this will help someone.Not that this should change the fix, as its clearly need for the real world cases, but, out of interest, RFC 7232 describing the
304response appear does require the server to send back theETag