Surely, surely, surely there is a way to configure the .Net HttpWebRequest object so that it does not raise an exception when HttpWebRequest.GetResponse() is called and any 300 or 400 status codes are returned?
Jon Skeet does not think so, so I almost dare not even ask, but I find it hard to believe there is no way around this. 300 and 400 response codes are valid responses in certain circumstances. Why would we be always forced to incur the overhead of an exception?
Perhaps there is some obscure configuration setting that evaded Jon Skeet? Perhaps there is a completely different type of request object that can be used that does not have this behavior?
(and yes, I know you can just catch the exception and get the response from that, but I would like to find a way not to have to).
Thanks for any help
According to the specification when a server sends a 400 status code it means that:
So it looks pretty natural to have an exception in this case. As far as 300 is concerned it is more debatable.
Anyway, if you want some non-standard behavior you can always resort to a TcpClient but that really seems like an extreme and desperate measure.
Did you perform performance tests? Have you confirmed that throwing an exception in this exceptional case is a bottleneck to your application? It seems like a micro optimization in this case. Can’t you make this web server happy by forging a valid request and getting 200 at the end? If not can’t you switch to a more standard web server?