Re: WebServices and .NET
"Lew" <lew@lewscanon.nospam> wrote in message
news:7vadnUuzl-a1ve7bnZ2dnUVZ_hninZ2d@comcast.com...
DTLLLUmpireSchedules@gmail.com wrote:
On May 12, 3:56 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
MikeSchillingwrote:
"Arne Vajh?j" <a...@vajhoej.dk> wrote ...
MikeSchillingwrote:
"Arne Vajh?j" <a...@vajhoej.dk> wrote
For some servlet containers you will need to tell the .NET
developers to put:
ServicePointManager.Expect100Continue= false;
in their program to avoid confusing the servlet container.
Which containers have you found this to be necessary for?
Tomcat.
Odd. At my workplace, we combine .NET clients and services deployed in
Tomcat(4.0 and 5.5) with some frequency (e.g. in the nightly unit
tests),
don't set that flag, and haven't seen any problems.
It may very likely only be certain combinations of versions.
If you google for it, then you find several stories where it
was necessary to make it work.
Obviously those without the problem never posted so.
And now we've run into it, and this information is invaluable. score
one for Usenet, and thanks, Arne.
At a project last year our team used Apache Web server as a front end to
Tomcat running Apache Axis to do Web services connecting to both J2EE
clients and .Net clients. All we had to do was make the WSDL specify
"document-literal" and follow certain Microsoftisms to assure
interoperability.
Could it be that we were lucky that either Apache Web Server lacks the
issue or that that version did?
DTLLLUmpireSchedules is me, by the way (it's the gmail account I use to
send out Little League schedules, and the thread was old enough that I could
only access it from Google Groups).
We see the issue with .NET 2.0 clients communicating with Tomcat 5.5
services running under JDK1.5. All three of these versions are different
from the situations where we didn't see it, and I don't know which are
important. The issue seems to be a Microsoft bug pure and simple. The
clients issue requests with the "Expect:100-continue" header, which means
that they'll wait to get a status message back before sending the body of
the request. They then send the body of the request without waiting,
confusing the hell out of the service.