By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,732 Members | 1,397 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,732 IT Pros & Developers. It's quick & easy.

HTTP Post and HttpWebRequest object

P: n/a
We have implemented a 'HTTP Post' client in C# that posts Xml documents to a
webserver. This is working fine if the post rate is one post for every 20
seconds. But if the post rate is increased to one post for every 10 seconds
the client start getting error 403 'forbidden' from the webserver after a
short period of time. The webserver is IIS. The choking of the client/server
communication when doing high frequency posting is due to that we create a
new HttpWebRequest object for each post. We have tried to reuse the
HttpWebRequest object but with no success. Only if using 'HTTP Get' are we
able to resue the HttpWebRequest object and able to 'Get' one document per
second. But also for 'Http Get' we observe the same behavior with the
client/server communication choking when creating a new HttpWebRequest object
for each 'HTTP Get'. I.e. the 'HTTP Get' behavior led us to belive that it is
the recreation of a HttpWebRequest object for each request/post that is the
problem.

We need a way to reuse the HttpWebRequest object for 'HTTP Post' or a more
light weight creation of the HttpWebRequest objects so that the client is
able to post one document per seconds for an extensive period of time.

Is this a know problem?

What is the best practice to do high frequency HTTP Post's using C# and IIS?

regards, /jansenh
May 28 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I think you should see IIS Log file first, this will give you insight into
exact problem. But I can advise you few thingsL
This kind of error sometime occurs when you do HTTP Protocol Violation. This
can be due to the incorrect or incomplete UserAgent header. Try this line

request.UserAgent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET
CLR 1.1.4322)"

Moreover HTTP protocol violation can be ignored, if you specify
UseUnsafeHeaderParsing=true in the configuration file.
HttpWebRequest.UseUnsafeHeaderParsing property is internal and read-only and
can't be changed for particular instance of HttpWebRequest.

If you feel that my post help you please provide feedback for me.
"JansenH" wrote:
We have implemented a 'HTTP Post' client in C# that posts Xml documents to a
webserver. This is working fine if the post rate is one post for every 20
seconds. But if the post rate is increased to one post for every 10 seconds
the client start getting error 403 'forbidden' from the webserver after a
short period of time. The webserver is IIS. The choking of the client/server
communication when doing high frequency posting is due to that we create a
new HttpWebRequest object for each post. We have tried to reuse the
HttpWebRequest object but with no success. Only if using 'HTTP Get' are we
able to resue the HttpWebRequest object and able to 'Get' one document per
second. But also for 'Http Get' we observe the same behavior with the
client/server communication choking when creating a new HttpWebRequest object
for each 'HTTP Get'. I.e. the 'HTTP Get' behavior led us to belive that it is
the recreation of a HttpWebRequest object for each request/post that is the
problem.

We need a way to reuse the HttpWebRequest object for 'HTTP Post' or a more
light weight creation of the HttpWebRequest objects so that the client is
able to post one document per seconds for an extensive period of time.

Is this a know problem?

What is the best practice to do high frequency HTTP Post's using C# and IIS?

regards, /jansenh

May 28 '06 #2

P: n/a
Thus wrote jansenh,
We have implemented a 'HTTP Post' client in C# that posts Xml
documents to a webserver. This is working fine if the post rate is one
post for every 20 seconds. But if the post rate is increased to one
post for every 10 seconds the client start getting error 403
'forbidden' from the webserver after a short period of time. The
webserver is IIS. The choking of the client/server communication when
doing high frequency posting is due to that we create a new
HttpWebRequest object for each post. We have tried to reuse the
HttpWebRequest object but with no success. Only if using 'HTTP Get'
are we able to resue the HttpWebRequest object and able to 'Get' one
document per second. But also for 'Http Get' we observe the same
behavior with the client/server communication choking when creating a
new HttpWebRequest object for each 'HTTP Get'. I.e. the 'HTTP Get'
behavior led us to belive that it is the recreation of a
HttpWebRequest object for each request/post that is the problem.

We need a way to reuse the HttpWebRequest object for 'HTTP Post' or a
more light weight creation of the HttpWebRequest objects so that the
client is able to post one document per seconds for an extensive
period of time.


I don't see why the number of actual HttpWebRequest instances has anything
to do with a server-side problem. Simply create one instance per request
-- that's the underlying model. Can you post your code?

Cheers,
--
Joerg Jooss
ne********@joergjooss.de
May 31 '06 #3

P: n/a
Thus wrote Altaf,
I think you should see IIS Log file first, this will give you insight
into
exact problem. But I can advise you few thingsL
This kind of error sometime occurs when you do HTTP Protocol
Violation. This
can be due to the incorrect or incomplete UserAgent header. Try this
line
request.UserAgent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
.NET CLR 1.1.4322)"
Not providing a User-Agent header isn't a protocol violation. But it's true
that many web applications rely on this header, and blissfully crash if it's
not there ;-)
Moreover HTTP protocol violation can be ignored, if you specify
UseUnsafeHeaderParsing=true in the configuration file.
HttpWebRequest.UseUnsafeHeaderParsing property is internal and
read-only and can't be changed for particular instance of
HttpWebRequest.


If there was a protocol violation, the OP should receive a WebException.

Cheers,
--
Joerg Jooss
ne********@joergjooss.de
May 31 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.