Prev: 16-bit greyscale photos in Tk
Next: Can Someone please help me with my Computer stuff? 12260
From: schlenk on 12 Feb 2010 16:44
On 27 Jan., 06:41, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
> On Jan 26, 11:37 am, Mark-in-TN <mark050...(a)yahoo.com> wrote:
>
> > I'm receiving an "HTTP/1.1 100 Continue" response from a .Net web
> > service.
> > How should I handle this response from within the WS::Client::DoCall
> > method?
>
> Copied from some .NET forum:
>
> 923507    The HTTP protocol stack in Windows Server 2003 sends a "100
> Continue" packet to the client even though the HTTP request does not
> contain an "Expect: 100-Continue" header
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;923507
>
> Anyone surprised?

Not really.

But at least Tcl http does not 'mishandle' the 100 continue like the
Pythons httplib does (it simply ignores it, even if you really need it
for your protocol).

Basically 100-continue is a funny beast, you can use it to ask the
server if he can handle your request (e.g. a huge multi megabyte POST
request) before starting to send your real data body. It really
deviates from the usual processing path for a a http request as you
get an intermediate result before a final result and need to structure
the interaction differently due to it.

So a correct way to handle it in the http package would probably be:
- If you do not send a Expect: 100-Continue header first just ignore
it in any response and wait for the real result code and response
- If you send an Expect: 100-Continue header it should call some
callback when the first response arrives to either send the body or
handle the errorcode

Michael
From: tom.rmadilo on 12 Feb 2010 20:01
On Feb 12, 1:44 pm, schlenk <schl...(a)uni-oldenburg.de> wrote:
> On 27 Jan., 06:41, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
>
>
>
>
>
> > On Jan 26, 11:37 am, Mark-in-TN <mark050...(a)yahoo.com> wrote:
>
> > > I'm receiving an "HTTP/1.1 100 Continue" response from a .Net web
> > > service.
> > > How should I handle this response from within the WS::Client::DoCall
> > > method?
>
> > Copied from some .NET forum:
>
> > 923507    The HTTP protocol stack in Windows Server 2003 sends a "100
> > Continue" packet to the client even though the HTTP request does not
> > contain an "Expect: 100-Continue" header
>
> >http://support.microsoft.com/default.aspx?scid=kb;EN-US;923507
>
> > Anyone surprised?
>
> Not really.
>
> But at least Tcl http does not 'mishandle' the 100 continue like the
> Pythons httplib does (it simply ignores it, even if you really need it
> for your protocol).
>
> Basically 100-continue is a funny beast, you can use it to ask the
> server if he can handle your request (e.g. a huge multi megabyte POST
> request) before starting to send your real data body. It really
> deviates from the usual processing path for a a http request as you
> get an intermediate result before a final result and need to structure
> the interaction differently due to it.
>
> So a correct way to handle it in the http package would probably be:
> - If you do not send a Expect: 100-Continue header first just ignore
> it in any response and wait for the real result code and response

The problem with ignoring the 100-continue header is that the server
expects you to (re)send the content (the server is already screwed up
if it sends such a response). This is hugely different from sending a
message and waiting for the result. The fact that the client did not
send the 100-continue header is iron clad evidence that the client
does not expect (and should not be prepared to handle) this type of
negotiation.

One principle which seems to be lost on most developers is that HTTP
communication is a lowest-common-denominator affair. Unless one side
signals a capability and the other side accepts, nothing is
guaranteed. In this case the client must signal use of the 100
continue before the server can use it.

> - If you send an Expect: 100-Continue header it should call some
> callback when the first response arrives to either send the body or
> handle the errorcode

My advice is to never use anything but the most basic methods unless
you are developing a generic browser. Otherwise each method must be
reflected up into the application API. If your application does not
understand a method, it should not use it. In this particular case, it
appears that the IIS layer is adding non-application level logic. It
is just a bug. Lower layers should not add anything new to the
communication protocol. (Of course: IIS: who is surprised?)

First  |  Prev  | 
Pages: 1 2
Prev: 16-bit greyscale photos in Tk
Next: Can Someone please help me with my Computer stuff? 12260