WebClient.UploadString(uri,string) hangs

[jrenae]

Hello,

We've been using the same WebClient.UploadString(uri,string) code for a few years now and it's worked fine. I'm implementing a new client and need to upload to a url that has an exe extension with a querystring and parameters. Also, it's https rather than http. I know I can reach the url as it works fine on our first pass (ping) which uses different code and a different class (HTTPWebRequest). But when I do the second pass (post) the UploadString method hangs for around 10 minutes and then returns nothing. It's not feasible for me to change the post code to use the HTTPWebRequest class as it will put our delivery to existing clients at risk. The method is a POST rather than a GET. I keep thinking that I've got the url wrong but it's exactly the same as the first pass. Someone thought I had to explicitly set the Content-Length header, but that throws the error 'This header must be modified using the appropriate property. Parameter name: name' when invoking the UploadString method. Is anyone aware of issues with using WebClient.UploadString when posting to a exe file with a querystring?

 

[jmeckley]

are you actually uploading a file, or just a string with the text ".exe" in it? if you need to upload a file then you need to post using the appropriate headers to designate a file upload. I believe the action must be a POST as well.

You may also want to monitor the request (firebug or fiddler) or see what's happening as well.

How does HTTPWebRequest put your clients are risk?

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[jrenae]

the exe is part of the url to which I'm trying to post. So it's something like '

https://somedomain.com/cgi-bin/filename.exe?id=xxxx&pr=i'.

The content I actually post is XML in a string. The risk of changing our code from using WebClient to HTTPWebRequest is that I'd be changing it for one particular client, but would have to make sure we can still successfully post to 100's of clients that are currently working with the WebClient to make sure they still work with the HTTPWebRequest.