HttpWebRequest POST method Expect header bug

[Guest]

I tried to report this as a bug but the reporting site encountered an error
when I hit submit. Anyone else ran into this? Anyone want to pass it along to
the appropriate group within MS?

There are actually four problems:

1) Anytime a POST method is used with the HttpWebRequest or WebRequest class
and a content length is set, an Expect header (Expect: 100-Continue) is
included in the inbound http headers. When the 100 status is received from
the server a call to getResponse on the request object throws and exception
indicating that it cannot read the received data.

2) If the target of the request (http server) in problem #1 does not support
the Expect header, an error status is received and the request also fails.

3) It is not possible to turn off the sending of the Expect header in the
Compact Framework as the System.Net.ServicePointManager.Expect100Continue
property does not exist and any attempt to set the Expect property of the
HttpWebRequest manually is overridden. The only way to turn it off is to
downgrade to HTTP 1.0 or use a GET method.

The above three problems essentially eliminate the possibility of using a
POST request from the compact framework.

4) The Expect header should not be set by default when a content length is
specified. Even if problem #1 were fixed so that the getResponse request did
not result in an exception, sending the Expect header by default causes two
unnecessary line flows and confuses developers. The confusion results in the
fact that one would have to issue a getResponse to pick up the 100 status
code, then send the POST data, then issue a getResponse again to get the real
response. This is silly.

In searching for a solution to this problem there are quite a number of
people experiencing the same problem in both the compact framework and the
standard .NET framework. There is a work around for the standard .NET
framework, but not the compact framework. The default should be that the
Expect header is never sent unless explicitly set by the developer.

This is a problem in 2003 .NET framework with SP3 applied as well.

 

[Andreas Selle]

Hi,

a work-around is to not set the ContentLength at all and set
AllowWriteStreamBuffering to true. At least this way I got the HTTP POST
working.

I am also surprised that this well-known bug was never fixed although it
exists since the very first release of the .NETCF.

There is another bug, which I do not have a solution for, yet: On new
Smartphones (or hard-reset Smartphones) it is not possible to establish any
HTTP SSL connection. Any such attempt fails with a SecureChannelFailure.
Surprisingly enough, it works after the Pocket IE has been used to navigate
to a SSL page. Must be that some vital SSL setup is missing which is only
done by Pocket IE.

Cheers,

Andreas

 

[Guest]

Andreas:

a work-around is to not set the ContentLength at all and set
AllowWriteStreamBuffering to true.

I did not try the AllowWriteStreamBuffering since their examples show that
the content length must still be set. Reports from other sites are that the
problem with the Expect header occurs whenever content length is set or
Chunked encoding is specified. Judging from my expirence I would say this is
correct. I'm surprised that the receiving side would be able to process the
POST data if content length was not present in the headers flowing with the
POST request. Not knowing the length of the incomming stream, it seems like
the server would hang a read out that would only be terminated if the socket
were closed. I will give it a try though. Thanks.

Andreas:

There is another bug, which I do not have a solution for, yet: On new
Smartphones (or hard-reset Smartphones) it is not possible to establish
any HTTP SSL connection.

That would be a very serious problem. Thanks for the heads up. One has to
wonder if some of this stuff was QA'ed prior to ship or worse yet if someone
actually beleives that the behaviors are correct.