Clarification on 100-Continue issues
mikeabdullah opened this issue · comments
Hello,
I ran into a similar problem with NSURLConnection et al years ago, that 100-Continue support was non-existant.
Fairly recently I got round to filing a radar asking for this feature, and was surprised to receive a response that it is supported — since "at least" OS X 10.7 — simply by:
set the "Expect" header to "100-continue"
I'm curious, did you ever try this? Indeed, did you ever try dropping down to the CFHTTPStream level either?
Hey Mike,
Yeah, indeed I tried but after testing it with a custom-built mini server (using Netty) I have no reason to believe it does work as I expected it to work.
There's nothing on the documentation that leads me to believe that I'd get this behavior by using CFHTTPStream. If anything, it should be otherwise (NSURLConnection be smarter than its CF counterpart). But then again I haven't tried it, so I can't really tell.
The problem is that the RFC (section 8.2.3) allows ambiguous scenarios and thus clients "SHOULD NOT" wait indefinitely for the 100-Continue response. For instance, libcurl waits 1 second (hardcoded in transfer.c) for the 100-Continue response and then proceeds with the upload . I've seen the .NET HTTP framework completely fail (417 Expectation failed) if no 100-Continue is received. I've opened a similar bug with Apple and got the same response so maybe NSURLConnection's waiting period is too short to be noticeable...
When I built BBHTTP, I was sure I'd be hitting servers that properly support the 100-Continue directive and thus I actually preferred the behavior of completely failing rather than uploading without a 100-Continue. If you look on line 120 of BBHTTPExecutor you'll find a workaround for curl's default behavior.
There's nothing on the documentation that leads me to believe that I'd get this behavior by using CFHTTPStream. If anything, it should be otherwise (NSURLConnection be smarter than its CF counterpart). But then again I haven't tried it, so I can't really tell.
Arguably, yes NSURLConnection should be the smarter of the pair, but CFHTTPStream should be the more capable. i.e as NSURLConnection's HTTP support is built atop CFNetwork, there shouldn't be any features available only at the higher Cocoa level. But NSURLConnection should do more work for you automatically.
So I'm still not too clear here; you tried setting the custom header for NSURLConnection, and then saw what behaviour, exactly?
Sorry for not making it clear in the previous comment; yes I did try setting the header and no, I did not see any noticeable delay between the headers being sent and the POST/PUT body being sent.
With curl I could see a 1 second delay (which works exactly as expected after inspecting curl's code) but with NSURLConnection I didn't observe this behavior. Things may have changed meanwhile but the point is I wanted strict compliance in the sense that the client should not send any data before the 100-Continue provisional response. Hence my workarounds for curl's non-configurable 100-Continue handling behavior.
With the risk of going a little bit off-topic, the main reason why I built BBHTTP was that NSURLConnection didn't properly handle error responses before it had finished sending all the data — and curl did.
I agree this can be closed. Just thought I'd note we've been playing with NSURLConnection's support for 100-Continue on the desktop and it seems fairly decent to me. I guess we don't quite the same server requirements as you!
How long does it wait for the 100-Continue response before it starts pumping data?
Also, the main reason behind BBTTP was:
(...) that NSURLConnection didn't properly handle error responses before it had finished sending all the data — and curl did.
Being able to manage how long I can wait for the 100-Continue is just a bonus.
I think we were seeing it wait about 3 seconds. Would have to check though. We also need to do more testing with big files.
Awesome. Can I ask you to drop me a line when you confirm this? Would love to update the README.
Cheers
Hi Bruno, my testing with Charles Proxy on 10.9 says that NSURLConnection will wait approx 4s before sending the body when using 100-continue. I haven't tried any earlier OS releases yet.