Re: Streamed HTTP POST request - no response if via Proxy
Re: Streamed HTTP POST request - no response if via Proxy
- Subject: Re: Streamed HTTP POST request - no response if via Proxy
- From: Jeremy Wyld <email@hidden>
- Date: Tue, 23 Nov 2004 06:50:10 -0800
On Nov 22, 2004, at 9:03 PM, daniel wrote:
I am using CFNetwork's CFReadStreamCreateForStreamedHTTPRequest to
perform an HTTP POST. This works great, except for when I'm working
through a proxy server. When I'm going through a proxy, the upload
appears to work fine, but the stream never appears to get a response
from the server when it's complete. I would suspect my proxy server,
but a user reported the problem against a completely different proxy
server.
These are the steps I'm following:
1. I set up an HTTP request with the desired upload URL.
2. Create a stream from the request, providing my upload data stream.
3. Attach proxy info to the stream (kCFStreamPropertyHTTPProxy).
4. Open the stream (all of my data is uploaded with no apparent errors
from either CFNetwork or from inspection with tcpdump).
5. Wait for there to either be bytes, an error, or for the status of
the stream to be "at end."
I end up waiting at step 5 until I finally time out with a stream
error of "-1". I assume CFNetwork has timed out on the request after
not seeing any activity for some time. At this point the read and
write buffers to the proxy server are both empty.
Do you see traffic coming back from the server through tcpdump? You
stated that you watch the traffic go up with tcpdump, but you didn't
state anything about traffic on return. Was there absolutely none?
Do you have control over the connection between the proxy and the
server? Can you tcpdump that? Do you see traffic there?
Now for my dark confession: I'm using a unix-domain socket read/write
stream to provide the data for the upload. I know, the shame! But
the fact is it's been working wonderfully in every other regard. Am I
naive to think I could get away with this? I don't really understand
the "risk" part of unix-domain sockets not being supported. I have
just seen references about it on this list. Does "not supported" mean
that I will run into occasional quirks like this - or is there
something more heinous to fear? Assuming I want to continue to "take
my chances" - are there any guesses as to how I might get around this
problem?
Unix domain sockets are not tested on a regular basis as are tcp
sockets. The primary target for CFSocketStream since first
implementation has been tcp sockets. That's not to say unix domain
sockets won't ever work; it just means that they have not been the
focus of attention. The other issue is that we can not guarantee the
API contract we have with the developer when unix domain sockets are
used. Some of the underlying constructs don't work with unix domain
sockets. I believe there is only one of those that is used, but I
could be wrong. Until we can guarantee that they work 100% (or what we
think is 100%), we can't advertise that they do work. I'll tell you
right now that the chances of unix domain sockets working is much
better than other random fd types though. If this sort of support is
high on the list of developers, you should make sure to file bugs so
the work gets ranked appropriately.
As for what to do next, I suggest watching the proxy traffic too.
Make sure there is nothing be dropped on the floor upstream from you.
Other things which you may wish to give attention:
Is the data chunked or are you passing a content length header? Try
using the other method if possible.
Are you attempting to use a persistent connection? What if you don't?
jeremy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden