> @@ -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();
@andrewgaul: Thanks for explaining the logic. If I understand correctly, this
is specifically a problem in cases where we know we will get a non-2xx response
code? In that case, could we create a separate test case that explicitly
expects a 401? In such a test, I can indeed imagine that we would work around
this problem in this way...
Would you agree with the assessment that this is annoying but not really a
_jclouds_ bug because
* the Expect: 100-continue header is necessary/should be there
* the actual HTTP call that causes the problem would, in general (although not
here in this test) not be made via jclouds
If either of those two assumptions is incorrect, should we be filing a bug to
either not set the header or make the jclouds HTTP utils handle this case
properly?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/183/files#r6996255
