Re: HttpWebRequest POST method Expect header bug
From: Andreas Selle (me_at_privacy.net)
Date: 03/03/05
- Next message: Dan: "Re: Using assembly.load to load system.data"
- Previous message: Aaron: "Re: Signature Capture"
- In reply to: RonS: "HttpWebRequest POST method Expect header bug"
- Next in thread: RonS: "Re: HttpWebRequest POST method Expect header bug"
- Reply: RonS: "Re: HttpWebRequest POST method Expect header bug"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 3 Mar 2005 07:44:34 +0100
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
"RonS" <RonS@discussions.microsoft.com> schrieb im Newsbeitrag
news:84ED3F7F-3A3A-4EAE-8D83-473101D04EE0@microsoft.com...
>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.
- Next message: Dan: "Re: Using assembly.load to load system.data"
- Previous message: Aaron: "Re: Signature Capture"
- In reply to: RonS: "HttpWebRequest POST method Expect header bug"
- Next in thread: RonS: "Re: HttpWebRequest POST method Expect header bug"
- Reply: RonS: "Re: HttpWebRequest POST method Expect header bug"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|