HTTPS bug with web services in .NET CF v2.0?

[Iain McGinniss]

Hello all,

I am writing a .NET Compact Framework v2.0 application which
communicates with a back-end system via a web service, using HTTPS for
transport. I am experiencing a problem where the first 256 characters
of the request are mysteriously cropped from the message before they
arrive at the server side. If I make the request over HTTP, it is
received correctly, so it only seems to be HTTPS which is causing the
problem. If I import the web reference into a desktop .NET Framework
application and call it from there over HTTPS it also works fine, I
have tried it using Apache Axis with Java as well which worked fine. As
such, the problem seems limited to the .NET Compact Framework. I am
about to try it with a v1.0 Compact Framework program to see whether
this is something that has been introduced since then.

Has anyone else come across a similar problem? Is it a known bug? If
so, are there any workarounds?

Thanks in advance,
Iain McGinniss

 

[Iain McGinniss]

I have now managed to send a request manually to my web service using a
HttpWebRequest object over HTTPS. The setting which seems to be causing
the problem is AllowWriteStreamBuffering - when this is set to true and
a ContentLength is not specified, I get the same error as I get when
sending my request using the web service APIs. If is set
AllowWriteStreamBuffering to false and specify a ContentLength, the
request is dispatched correctly.

To give some extra information on my original problem, we were sending
a message of length 428 characters to the web service. When the server
reads from the stream, the first 256 characters of that message have
been cropped. It then receives up to the end of the message correctly,
then it receives a *second* copy of the message, but with the first 172
characters cropped from the start. The result is a message of length
428, as expected, containing two partial copies of the message with
differing numbers of bytes missing from the front.

It may be coincidence, but when you inspect the internals of the stream
that is provided by HttpWebRequest.getRequestStream() with
AllowWriteStreamBuffering to true, the first buffer it creates is of
length 256.

Does anyone know why this would be happening when I make HTTPS
requests? We have been tearing our hair out for three days trying to
get to the bottom of this problem. Right now we are considering writing
a custom WebRequest implementation which wraps a HttpWebRequest with
AllowWriteStreamBuffering set to false, and sets the content length and
streams through the message once the full message has been written to
the custom implementation's request stream. I can only hope that will
work...

 

[Daniel]

Hi Iian,

I'm also tearing my hair out. Have you come to a solution with this
problem? Did you write a custom?

Thanks for help,

Daniel

Iain McGinniss skrev: