HttpWebRequest Question - 25 days, 2 re-posts, no answers :(

  • Thread starter Thread starter furty
  • Start date Start date
F

furty

I've hit a brick wall with this one..

I'm trying to perform a HttpWebRequest that posts form data to the target
server - the problem is that the request *always* contains an Expect:
100-continue header, which on HTTP 1.0 servers results in a 500 error.

None of these seemingly obvious fixes work:

Set the HttpWebRequest.Expect property to null or String.Empty
Set the HttpWebRequest.ProtocolVersion to HttpVersion.Version10

Note that my class works perfectly with HTTP 1.1 servers, so I doubt there's
anything I've done incorrectly in code. Also note that the problem only
surfaces when you POST data to the server with the request, no post data =
no problem.

Searching google for this problem has given me a few people that have hit
the same problem, but not one valid workaround.

Help!
 
Does it return a 500 error from _all_ HTTP 1.0 servers, or just the one
you're having problems with?
Click to expand...
It returns a 500 error for 15 different HTTP 1.0 servers I need to POST data
to.
Is there something illegal about a Expect header in HTTP 1.0?
Click to expand...
Yes. The Expect header does not exist in the HTTP 1.0 specification.
Maybe you haven't received answers because you're looking on the client and
not on the server.
Click to expand...
The fault lies with the client, not the server. Returning a 500 error is
perfectly acceptable behaviour for a server if it receives badly formed, or
out of spec headers.
 
furty said:
It returns a 500 error for 15 different HTTP 1.0 servers I need to POST data
Yes. The Expect header does not exist in the HTTP 1.0 specification.

The fault lies with the client, not the server. Returning a 500 error is
perfectly acceptable behaviour for a server if it receives badly formed, or
out of spec headers.
Click to expand...

Really? What did the HTTP 1.0 spec say about unknown headers? What does 1.1
say?
 
John, I'm really not interested in entering into a pissing contest, all I'm
after is a valid workaround for a flaw in the HttpWebRequest implementation.
If you've got some information that can assist me in getting a working
result I'd be more than appreciative.
 
furty said:
John, I'm really not interested in entering into a pissing contest, all I'm
after is a valid workaround for a flaw in the HttpWebRequest
Click to expand...
implementation.

Sorry if it seems that way. I was really asking the question. I haven't read
the 1.0 protocol spec and it seems you have.
If you've got some information that can assist me in getting a working
result I'd be more than appreciative.
Click to expand...

BTW, you have the answer yourself. HttpWebRequest won't do what you want. So
don't use it. Write your own. I doubt you've been sitting on your hands for
25 days, but it shouldn't take more than a week for you to write your own
WebRequest subclass adequate to your needs.
 
furty said:
My apologies John, I guess I'm starting to lose patience with this problem,
and needed to vent.
Accepted.

The basics of expect 100-continue when POSTing data to a HTTP 1.1 server are
this:

Client sends header data only, with an expect 100-continue
Server responds with a handshake
Client sends POST (body) data.

The problem is that HTTP 1.0 does not support expect 100-continue, and so it
expects that the POSTed body data is sent with the original message. As the
body data is missing, it throws an error.
Click to expand...

Thanks. From what you'd said earlier, I thought the problem was the header
itself, and that's why I was asking about how the protocol was meant to
handle unknown headers. If the POST data aren't being sent, I can understand
a 500 error.
want.

Of course you are right, that is the ultimate fix. The problem is that I've
already got a massive workload, and I just can't beleive that MS have let
such a glaringly obvious flaw slip through 2 service packs and a new version
of the framework.
Click to expand...

My point was that it's obviously not obvious if there are so few people
complaining about it! How many HTTP 1.0 servers are there still out there?

I suppose these are embedded systems so that there's no chance of upgrading
them even a little?
 
My point was that it's obviously not obvious if there are so few people
complaining about it! How many HTTP 1.0 servers are there still out there?

I suppose these are embedded systems so that there's no chance of upgrading
them even a little?
Click to expand...

While I don't have any specific data on the subject, in my experience HTTP
1.0 seems to be most prevalant with Apache SSL servers, though still
represents a high percentage of non-secure web servers out there. I guess
they are employing the "if it ain't broke, don't fix it" mentality, or
perhaps don't have the funding to roll-out costly updgrades to systems that
are working just fine.

To me, the only logical reason that more people are not complining about the
problem is becuase a lot of developers must have the luxury are
re-implementing existing HTTP/HTTPS services as WebServices. I unfortunately
don't have this luxury - the project I'm developing must automate existing
HTTP and HTTPS web sites as there are simply too many technical and
financial barriers to updagrading the 80 odd systems our application must
access.

Oh well, I guess I've got no choice :(
 
Back
Top