HTTP 304 Not Modified response from S3 object store not proxied #848
Description
When the client uses client cache control HTTP headers like if-none-match: "4407d4e833a9dccd7c755f3f78ef1028" and the ETag matches the currently stored content, then the S3 object store returns an HTTP 304, meaning that the content did not change. This is for example used by Browsers for locally caching e.g. images, this means that just not sending these headers is sometimes out of control of the service operator.
Unfortunately in the jclouds library every response with HTTP status >= 300 is treated as an error, instead of only HTTP status >= 400.
See org.jclouds.http.internal.BaseHttpCommandExecutorService.java:106
Thus instead of proxying the small HTTP 304 response to the client, s3proxy returns an error.
Caused by: org.jclouds.http.HttpResponseException: command:
GET https://<domain>/<bucket>/uploads/image.png HTTP/1.1 failed with response: HTTP/1.1 304 Not Modified; content: []
at org.jclouds.aws.handlers.ParseAWSErrorFromXmlContent.handleError(ParseAWSErrorFromXmlContent.java:78)
at org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:63)
at org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:138)
at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:107)
at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
at jdk.proxy2/jdk.proxy2.$Proxy56.getObject(Unknown Source)
at org.jclouds.s3.blobstore.S3BlobStore.getBlob(S3BlobStore.java:235)
As jclouds is already out of support, a fix in there is probably no longer possible.
I guess this would be fixed by migrating to the AWS SDK for this storage backend too? #750
Version: S3Proxy 2.7.0
Backend: JCLOUDS_PROVIDER=s3
Encryption middleware was active too, but I think the error should also be present without that middleware.