-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADD from url fails with 'invalid not-modified ETag' #905
Comments
Also seeing it from github releases, such as:
|
I believe I understand the cause.The fix should be very simple 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 Background infoDocker version infoDocker for Mac 2.1.1.0 (27260)Client: Debug Mode: false Plugins: app: Docker Application (Docker Inc., v0.8.0) buildx: Build with BuildKit (Docker Inc., v0.2.2-10-g3f18b65-tp-docker) Reproduction Steps
|
respETag := resp.Header.Get("ETag") | |
si, ok := m[respETag] | |
if ok { | |
hs.refID = si.ID() |
buildkit/source/http/httpsource.go
Lines 197 to 203 in bcd466a
} | |
if resp.StatusCode == http.StatusNotModified { | |
respETag := resp.Header.Get("ETag") | |
si, ok := m[respETag] | |
if !ok { | |
return "", false, errors.Errorf("invalid not-modified ETag: %v", respETag) | |
} |
If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed description, see: moby#905 (comment)
If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed description, see: moby#905 (comment) Signed-off-by: Robert Estelle <[email protected]>
Not that this should change the fix, as its clearly need for the real world cases, but, out of interest, RFC 7232 describing the
|
If a single ETag is requested in `If-None-Match`, some servers do not include that (unambiguous) ETag header in the response. For detailed description, see: moby#905 (comment) Signed-off-by: Robert Estelle <[email protected]> (cherry picked from commit c63c6f9)
full diff: moby/buildkit@f704282...ae10b29 fixes: - moby/buildkit#1144 Fix socket handling - fsutil: Handle copying unix sockets in local sources - update github.com/containerd/continuity to 75bee3e2ccb6 - update github.com/tonistiigi/fsutil to 3d2716dd0a4d - moby/buildkit#1150 ssh: Fix file descriptor leak when doing SSH forwarding - fixes moby/buildkit#1146 SSH Forwarding Doesn't Release File Descriptors - moby/buildkit#1156 llbsolver: Fix using multiple remote cache importers - moby/buildkit#1159 http: Handle missing but unambiguous ETags in response - fixes moby/buildkit#905 ADD from url fails with 'invalid not-modified ETag' - fixes moby/buildkit#784 invalid not-modified ETag with local network ADD in docker - moby/buildkit#1166 solver: Fix possible inefficient parallelization in solver - fix cases where some events were dropped resulting inefficient parallelization. - moby/buildkit#1168 vendor: update go-runc to e029b79d - moby/buildkit#1140 contenthash: Fix bug with symlink in source path of a copy operation - fixes moby/buildkit#974 COPY --from fails when source path involves a symlink - fixes moby/buildkit#785 COPY rpc error: code = Unknown desc = not found: not found - fixes moby/buildkit#958 Issue COPY a file to a symlink directory - moby/buildkit#1139 executor: oom_score_adj is no longer set from main process Signed-off-by: Sebastiaan van Stijn <[email protected]>
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. @jkfran found [this technique](https://stackoverflow.com/questions/36996046/how-to-prevent-dockerfile-caching-git-clone) of using `ADD` to query https://api.github.com/, but unfortunately it didn't work for me because I kept getting the error "invalid not-modified ETag" from GitHub. This [should have been fixed](moby/buildkit#905) but the fix doesn't seem to have made its way into latest docker-ce yet. So at some point in the future we could use this solution. For the time being I've instead used https://httpbin.org/uuid to create a cache-busting line in the `Dockerfile` just above the git clone. This is less efficient, in that the GitHub solution would allow GitHub to return a 304 if nothing had changed, which would allow Docker to make use of the further caching below that point, whereas in this implementation it will simply clone the repo every time. But I believe this is the best we can do for now.
Seems like this should have been fixed by #1159. Is the patch released already? I'm on |
I was getting this issue, but I found doing a |
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? |
To get around the |
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 |
Interesting, thanks for that @robinjoerke |
I'm also still having this issue with docker 20.10.8 |
I'm still having this issue with docker 20.10.11 (Docker for Windows) |
The original issue was fixed two years ago; if you encounter this, and have more details, please use #2420 instead. |
Still happening with Docker 20.10.18. No OAuth or authentication is involved:
|
And in "Docker version 20.10.20, build 9fdeb9c" too:
FROM php:8.0-cli
RUN export DEBIAN_FRONTEND=noninteractive && \
apt update && \
apt install -y --no-install-recommends \
git \
unzip \
&& \
rm -rf /var/lib/apt/lists/*
ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/
ADD https://getcomposer.org/download/2.1.14/composer.phar /usr/local/bin/ Output:
|
|
The error is produced by code that we use from BuildKit; in this part of the BuildKit code; buildkit/source/http/httpsource.go Lines 214 to 226 in efc6335
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)? |
And what can one do about it? Is it possible to kill the locally stored ETags somehow? |
@bronger this is a 4-year, nearly 5-year old ticket; if you're running into an issue on a current version of docker or buildkit, and have steps to reproduce that can help to investigate, please open a new ticket instead with steps to reproduce, and information about your environment. |
Just use |
Build fails at:
ADD https://getcomposer.org/composer.phar /usr/local/bin/composer
Log:
I'm wondering if this is related to #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.The text was updated successfully, but these errors were encountered: