> @@ -130,6 +131,10 @@ public void testSignPutUrlWithTime() throws Exception {
> String container = getContainerName();
> try {
> HttpRequest request = view.getSigner().signPutBlob(container, blob,
> 3 /* seconds */);
> + // Strip Expect: 100-continue since Java 7+ will throw a
> + // ProtocolException instead of setting the response code:
> + //
> http://www.docjar.com/html/api/sun/net/www/protocol/http/HttpURLConnection.java.html#1021
> + request = request.toBuilder().removeHeader(EXPECT).build();
Previously this test sent:
at time = 0
```
> PUT /foo?expires=5 HTTP/1.1
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 201 Created
```
at time = 10
```
> PUT /foo?expires=5 HTTP/1.1
> Expect: 100-continue
>
< HTTP/1.1 401 Unauthorizated
```
Since we do not receive 100-Continue, Java throws a ProtocolException instead
of letting jclouds propagate its AuthorizationException in response to the 401.
Stripping 100 here allows jclouds to see the real 401 error. I do not know if
we should prefer this approach; 100-continue handling seems fragile between
different services.
@diwakergupta relevant to your 100-continue investigation.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/183/files#r6978665
