HTTP Status 100

We have been getting users of our web sites complain about not receiving
responses to requests they send us. We are a property/casualty insurance
company and all of our agents use the sites to process quotes, pay bills, all
kinds of things.

From time to time we will have a user send information let's say so we can
quote an auto policy. (this happens with other type requests too) The user
sends the info, I can see the request hit 1 of our servers but the HTTP
status of the request is 100. IIS responses appropriately to send the
request, but the user says they never get back anything of the response for
the quote. Our servers never get the request to process quote data.

Would someone give me a place to look why this occurring? The #s are
increasing where this is happening.

These are 2003 web server machines with the proper IIS and I have had this
occur with users and browser versions 6.0 through 7. We are processing ASPX
requests using .Net 1.1.

The numbers of this type of incident are increasing. I see status 100
requests come in but most of the time they do get the actual request then to
process data. But sometimes we never see the final request.

We do trap and save to sessions all requests/responses so I can look not
only at what IIS is logging but also what the user is getting.

Thank you very much. All help is greatly appreciated.
Larry
--
Larry

Re: HTTP Status 100

Based on your description, I do not see anything wrong with IIS.

Can you describe why you think the user issue has to do with the "100
continue" response, and if it is the "100 continue", why the problem
is with IIS and not the remote client?


For example, your statement:
> The user sends the info, I can see the request hit 1 of our
> servers but the HTTP status of the request is 100. IIS
> responses appropriately to send the request, but the
> user says they never get back anything of the response for
> the quote. Our servers never get the request to process
> quote data.

You seem to indicate that "IIS responses appropriately to send the
request" but the HTTP status of 100 is unexpected. And that the user
never gets back the response and the server never get the request to
process quote data. Thus, you think that HTTP status 100 is the
"problem".

Actually, we will need the complete request from the client to
determine if the HTTP status 100 is expected or not. The HTTP/1.1 RFC
details what should happen, so we can easily look at the request and
determine who is at fault. You can't just look at client behavior to
determine if the 100 continue is expected or not.

For example, there are plenty of web clients who claim to handle 100
continue but cannot do it, so that would be a bug with the client.

At this point, it looks like the client chokes on 100 continue and
fails to post the actual quote request so the server does not process
data. If the request indicates that the 100-continue is ok, then this
would be a bug with the client. Maybe the clients are behind proxy
servers with bugs, etc.

I don't know of a way to "turn off 100 continue" on IIS6 because
HTTP.SYS will automatically send it at the right time when client
indicates it supports it. Your work-around for broken clients could be
to make your HTML FORMs use GET instead of POST.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Jul 6, 10:46 am, Larry wrote:
> We have been getting users of our web sites complain about not receiving
> responses to requests they send us. We are a property/casualty insurance
> company and all of our agents use the sites to process quotes, pay bills, all
> kinds of things.
>
> From time to time we will have a user send information let's say so we can
> quote an auto policy. (this happens with other type requests too) The user
> sends the info, I can see the request hit 1 of our servers but the HTTP
> status of the request is 100. IIS responses appropriately to send the
> request, but the user says they never get back anything of the response for
> the quote. Our servers never get the request to process quote data.
>
> Would someone give me a place to look why this occurring? The #s are
> increasing where this is happening.
>
> These are 2003 web server machines with the proper IIS and I have had this
> occur with users and browser versions 6.0 through 7. We are processing ASPX
> requests using .Net 1.1.
>
> The numbers of this type of incident are increasing. I see status 100
> requests come in but most of the time they do get the actual request then to
> process data. But sometimes we never see the final request.
>
> We do trap and save to sessions all requests/responses so I can look not
> only at what IIS is logging but also what the user is getting.
>
> Thank you very much. All help is greatly appreciated.
> Larry
> --
> Larry

Re: HTTP Status 100

Thank you David for your reply.

We collect every request/response that comes to our web site and they are
written into a session that we can replay back in a browser. The product is
called Tealeaf. Anyway, from that session, we can look at all the header
info, data, cookies, everything that is coming in as that request. Then as
the response is generated, that then is attched to that request and we can
see what is going back t the user.

The reason I can see the http 100 is because of looking at specific user
sessions when they have a problem. I can see the http 100 come in with a
blank response other than that which IIS sends back and then no more requests
come in. I compare that with the IIS logs - the http 100 does not record.

I do not believe this is an IIS issue but I am at a loss explaining what is
happening.

Why wouldn't the browser be processing the response to a 100 request?

Does the http 100 start at the browser? Isn't it asking if IIS is ready to
process a request - thus a response to continue?

Seems like a browser sending a 100 request should be processing the continue
response. But here again, I'm not a pro at what all this really means.

Thanks again for your reply.
--
Larry


"David Wang" wrote:

> Based on your description, I do not see anything wrong with IIS.
>
> Can you describe why you think the user issue has to do with the "100
> continue" response, and if it is the "100 continue", why the problem
> is with IIS and not the remote client?
>
>
> For example, your statement:
> > The user sends the info, I can see the request hit 1 of our
> > servers but the HTTP status of the request is 100. IIS
> > responses appropriately to send the request, but the
> > user says they never get back anything of the response for
> > the quote. Our servers never get the request to process
> > quote data.
>
> You seem to indicate that "IIS responses appropriately to send the
> request" but the HTTP status of 100 is unexpected. And that the user
> never gets back the response and the server never get the request to
> process quote data. Thus, you think that HTTP status 100 is the
> "problem".
>
> Actually, we will need the complete request from the client to
> determine if the HTTP status 100 is expected or not. The HTTP/1.1 RFC
> details what should happen, so we can easily look at the request and
> determine who is at fault. You can't just look at client behavior to
> determine if the 100 continue is expected or not.
>
> For example, there are plenty of web clients who claim to handle 100
> continue but cannot do it, so that would be a bug with the client.
>
> At this point, it looks like the client chokes on 100 continue and
> fails to post the actual quote request so the server does not process
> data. If the request indicates that the 100-continue is ok, then this
> would be a bug with the client. Maybe the clients are behind proxy
> servers with bugs, etc.
>
> I don't know of a way to "turn off 100 continue" on IIS6 because
> HTTP.SYS will automatically send it at the right time when client
> indicates it supports it. Your work-around for broken clients could be
> to make your HTML FORMs use GET instead of POST.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Jul 6, 10:46 am, Larry wrote:
> > We have been getting users of our web sites complain about not receiving
> > responses to requests they send us. We are a property/casualty insurance
> > company and all of our agents use the sites to process quotes, pay bills, all
> > kinds of things.
> >
> > From time to time we will have a user send information let's say so we can
> > quote an auto policy. (this happens with other type requests too) The user
> > sends the info, I can see the request hit 1 of our servers but the HTTP
> > status of the request is 100. IIS responses appropriately to send the
> > request, but the user says they never get back anything of the response for
> > the quote. Our servers never get the request to process quote data.
> >
> > Would someone give me a place to look why this occurring? The #s are
> > increasing where this is happening.
> >
> > These are 2003 web server machines with the proper IIS and I have had this
> > occur with users and browser versions 6.0 through 7. We are processing ASPX
> > requests using .Net 1.1.
> >
> > The numbers of this type of incident are increasing. I see status 100
> > requests come in but most of the time they do get the actual request then to
> > process data. But sometimes we never see the final request.
> >
> > We do trap and save to sessions all requests/responses so I can look not
> > only at what IIS is logging but also what the user is getting.
> >
> > Thank you very much. All help is greatly appreciated.
> > Larry
> > --
> > Larry
>
>
>

Re: HTTP Status 100

On Jul 6, 1:32 pm, Larry wrote:
> Thank you David for your reply.
>
> We collect every request/response that comes to our web site and they are
> written into a session that we can replay back in a browser. The product is
> called Tealeaf. Anyway, from that session, we can look at all the header
> info, data, cookies, everything that is coming in as that request. Then as
> the response is generated, that then is attched to that request and we can
> see what is going back t the user.
>
> The reason I can see the http 100 is because of looking at specific user
> sessions when they have a problem. I can see the http 100 come in with a
> blank response other than that which IIS sends back and then no more requests
> come in. I compare that with the IIS logs - the http 100 does not record.
>
> I do not believe this is an IIS issue but I am at a loss explaining what is
> happening.
>
> Why wouldn't the browser be processing the response to a 100 request?
>
> Does the http 100 start at the browser? Isn't it asking if IIS is ready to
> process a request - thus a response to continue?
>
> Seems like a browser sending a 100 request should be processing the continue
> response. But here again, I'm not a pro at what all this really means.
>
> Thanks again for your reply.
> --
> Larry
>
>
>
> "David Wang" wrote:
> > Based on your description, I do not see anything wrong with IIS.
>
> > Can you describe why you think the user issue has to do with the "100
> > continue" response, and if it is the "100 continue", why the problem
> > is with IIS and not the remote client?
>
> > For example, your statement:
> > > The user sends the info, I can see the request hit 1 of our
> > > servers but the HTTP status of the request is 100. IIS
> > > responses appropriately to send the request, but the
> > > user says they never get back anything of the response for
> > > the quote. Our servers never get the request to process
> > > quote data.
>
> > You seem to indicate that "IIS responses appropriately to send the
> > request" but the HTTP status of 100 is unexpected. And that the user
> > never gets back the response and the server never get the request to
> > process quote data. Thus, you think that HTTP status 100 is the
> > "problem".
>
> > Actually, we will need the complete request from the client to
> > determine if the HTTP status 100 is expected or not. The HTTP/1.1 RFC
> > details what should happen, so we can easily look at the request and
> > determine who is at fault. You can't just look at client behavior to
> > determine if the 100 continue is expected or not.
>
> > For example, there are plenty of web clients who claim to handle 100
> > continue but cannot do it, so that would be a bug with the client.
>
> > At this point, it looks like the client chokes on 100 continue and
> > fails to post the actual quote request so the server does not process
> > data. If the request indicates that the 100-continue is ok, then this
> > would be a bug with the client. Maybe the clients are behind proxy
> > servers with bugs, etc.
>
> > I don't know of a way to "turn off 100 continue" on IIS6 because
> > HTTP.SYS will automatically send it at the right time when client
> > indicates it supports it. Your work-around for broken clients could be
> > to make your HTML FORMs use GET instead of POST.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jul 6, 10:46 am, Larry wrote:
> > > We have been getting users of our web sites complain about not receiving
> > > responses to requests they send us. We are a property/casualty insurance
> > > company and all of our agents use the sites to process quotes, pay bills, all
> > > kinds of things.
>
> > > From time to time we will have a user send information let's say so we can
> > > quote an auto policy. (this happens with other type requests too) The user
> > > sends the info, I can see the request hit 1 of our servers but the HTTP
> > > status of the request is 100. IIS responses appropriately to send the
> > > request, but the user says they never get back anything of the response for
> > > the quote. Our servers never get the request to process quote data.
>
> > > Would someone give me a place to look why this occurring? The #s are
> > > increasing where this is happening.
>
> > > These are 2003 web server machines with the proper IIS and I have had this
> > > occur with users and browser versions 6.0 through 7. We are processing ASPX
> > > requests using .Net 1.1.
>
> > > The numbers of this type of incident are increasing. I see status 100
> > > requests come in but most of the time they do get the actual request then to
> > > process data. But sometimes we never see the final request.
>
> > > We do trap and save to sessions all requests/responses so I can look not
> > > only at what IIS is logging but also what the user is getting.
>
> > > Thank you very much. All help is greatly appreciated.
> > > Larry
> > > --
> > > Larry- Hide quoted text -
>
> - Show quoted text -



>Why wouldn't the browser be processing the response to a 100 request?

Because... maybe the browser has a bug?


HTTP 100 continue is an optimization. It is sent by the server to tell
the client to continue doing whatever it was going to do on that
request. It is used for sending entity body, in the following manner:
1. Client sends request without entity body to server
2. Server responds with 100 continue
3. Client sends entity body to server
4. Server response with status code of processing the request

Why is there 100 continue? Well, suppose the client is trying to make
a 4GB POST to a web application requiring authentication (suppose the
web application accepts large financial data files). Do you want the
request sequence to look like:
1. Client sends request with 4GB entity body to server
2. Server responds with 401 Authentication required
3. Client sends request with authorization header and 4GB entity body
to server AGAIN
4. Server responds with status code of processing the request

Why do you need to send at least 8GB of data to make a POST to an
authenticated applications?

With 100 continue, the client can send just the request header,
without 4GB entity body, telling the server "if you tell me to 100
continue, then I will send the 4GB entity body to you", and the server
can quickly tell the client "wait, you need to authenticate" or "go
ahead, send the entity body". The request sequence looks something
like:
1. Client sends request with "expect:" header WITHOUT 4GB entity body
to server
2. Server responds with 401 Authentication required
3. Client sends request with "expect:" and authorization header
WITHOUT 4GB entity body to server
4. Server responds with 100 continue
5. Client sends the 4GB entity body to server
6. Server responds with status code of processing the request

Notice that while there are 6 network request/response interactions
instead of 4 (which wastes negligible time and bandwidth), the second
version only transmits the 4GB entity body ONCE -- instead of
wastefully sending 8GB that takes non-negligible bandwidth and time.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: HTTP Status 100

Thanks David for your response.

Could I get you to reply on the information found at this URL?

http://support.microsoft.com/kb/898708/

Thanks
--
Larry


"David Wang" wrote:

> On Jul 6, 1:32 pm, Larry wrote:
> > Thank you David for your reply.
> >
> > We collect every request/response that comes to our web site and they are
> > written into a session that we can replay back in a browser. The product is
> > called Tealeaf. Anyway, from that session, we can look at all the header
> > info, data, cookies, everything that is coming in as that request. Then as
> > the response is generated, that then is attched to that request and we can
> > see what is going back t the user.
> >
> > The reason I can see the http 100 is because of looking at specific user
> > sessions when they have a problem. I can see the http 100 come in with a
> > blank response other than that which IIS sends back and then no more requests
> > come in. I compare that with the IIS logs - the http 100 does not record.
> >
> > I do not believe this is an IIS issue but I am at a loss explaining what is
> > happening.
> >
> > Why wouldn't the browser be processing the response to a 100 request?
> >
> > Does the http 100 start at the browser? Isn't it asking if IIS is ready to
> > process a request - thus a response to continue?
> >
> > Seems like a browser sending a 100 request should be processing the continue
> > response. But here again, I'm not a pro at what all this really means.
> >
> > Thanks again for your reply.
> > --
> > Larry
> >
> >
> >
> > "David Wang" wrote:
> > > Based on your description, I do not see anything wrong with IIS.
> >
> > > Can you describe why you think the user issue has to do with the "100
> > > continue" response, and if it is the "100 continue", why the problem
> > > is with IIS and not the remote client?
> >
> > > For example, your statement:
> > > > The user sends the info, I can see the request hit 1 of our
> > > > servers but the HTTP status of the request is 100. IIS
> > > > responses appropriately to send the request, but the
> > > > user says they never get back anything of the response for
> > > > the quote. Our servers never get the request to process
> > > > quote data.
> >
> > > You seem to indicate that "IIS responses appropriately to send the
> > > request" but the HTTP status of 100 is unexpected. And that the user
> > > never gets back the response and the server never get the request to
> > > process quote data. Thus, you think that HTTP status 100 is the
> > > "problem".
> >
> > > Actually, we will need the complete request from the client to
> > > determine if the HTTP status 100 is expected or not. The HTTP/1.1 RFC
> > > details what should happen, so we can easily look at the request and
> > > determine who is at fault. You can't just look at client behavior to
> > > determine if the 100 continue is expected or not.
> >
> > > For example, there are plenty of web clients who claim to handle 100
> > > continue but cannot do it, so that would be a bug with the client.
> >
> > > At this point, it looks like the client chokes on 100 continue and
> > > fails to post the actual quote request so the server does not process
> > > data. If the request indicates that the 100-continue is ok, then this
> > > would be a bug with the client. Maybe the clients are behind proxy
> > > servers with bugs, etc.
> >
> > > I don't know of a way to "turn off 100 continue" on IIS6 because
> > > HTTP.SYS will automatically send it at the right time when client
> > > indicates it supports it. Your work-around for broken clients could be
> > > to make your HTML FORMs use GET instead of POST.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Jul 6, 10:46 am, Larry wrote:
> > > > We have been getting users of our web sites complain about not receiving
> > > > responses to requests they send us. We are a property/casualty insurance
> > > > company and all of our agents use the sites to process quotes, pay bills, all
> > > > kinds of things.
> >
> > > > From time to time we will have a user send information let's say so we can
> > > > quote an auto policy. (this happens with other type requests too) The user
> > > > sends the info, I can see the request hit 1 of our servers but the HTTP
> > > > status of the request is 100. IIS responses appropriately to send the
> > > > request, but the user says they never get back anything of the response for
> > > > the quote. Our servers never get the request to process quote data.
> >
> > > > Would someone give me a place to look why this occurring? The #s are
> > > > increasing where this is happening.
> >
> > > > These are 2003 web server machines with the proper IIS and I have had this
> > > > occur with users and browser versions 6.0 through 7. We are processing ASPX
> > > > requests using .Net 1.1.
> >
> > > > The numbers of this type of incident are increasing. I see status 100
> > > > requests come in but most of the time they do get the actual request then to
> > > > process data. But sometimes we never see the final request.
> >
> > > > We do trap and save to sessions all requests/responses so I can look not
> > > > only at what IIS is logging but also what the user is getting.
> >
> > > > Thank you very much. All help is greatly appreciated.
> > > > Larry
> > > > --
> > > > Larry- Hide quoted text -
> >
> > - Show quoted text -
>
>
>
> >Why wouldn't the browser be processing the response to a 100 request?
>
> Because... maybe the browser has a bug?
>
>
> HTTP 100 continue is an optimization. It is sent by the server to tell
> the client to continue doing whatever it was going to do on that
> request. It is used for sending entity body, in the following manner:
> 1. Client sends request without entity body to server
> 2. Server responds with 100 continue
> 3. Client sends entity body to server
> 4. Server response with status code of processing the request
>
> Why is there 100 continue? Well, suppose the client is trying to make
> a 4GB POST to a web application requiring authentication (suppose the
> web application accepts large financial data files). Do you want the
> request sequence to look like:
> 1. Client sends request with 4GB entity body to server
> 2. Server responds with 401 Authentication required
> 3. Client sends request with authorization header and 4GB entity body
> to server AGAIN
> 4. Server responds with status code of processing the request
>
> Why do you need to send at least 8GB of data to make a POST to an
> authenticated applications?
>
> With 100 continue, the client can send just the request header,
> without 4GB entity body, telling the server "if you tell me to 100
> continue, then I will send the 4GB entity body to you", and the server
> can quickly tell the client "wait, you need to authenticate" or "go
> ahead, send the entity body". The request sequence looks something
> like:
> 1. Client sends request with "expect:" header WITHOUT 4GB entity body
> to server
> 2. Server responds with 401 Authentication required
> 3. Client sends request with "expect:" and authorization header
> WITHOUT 4GB entity body to server
> 4. Server responds with 100 continue
> 5. Client sends the 4GB entity body to server
> 6. Server responds with status code of processing the request
>
> Notice that while there are 6 network request/response interactions
> instead of 4 (which wastes negligible time and bandwidth), the second
> version only transmits the 4GB entity body ONCE -- instead of
> wastefully sending 8GB that takes non-negligible bandwidth and time.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>

Re: HTTP Status 100

Can you clarify if/why you think the KB applies to your situation?

Just reiterating what you have said -- the 100 continue is sent, the
client never receives the response, and the server never got the
request (assuming you trust what Tealeaf tells you).

KB mentions the 100 continue sent with the response, so the client
sees a response and the server got the request to generate the
response.

It seems like two separate things to me, but maybe you have additional
information that says otherwise.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jul 17, 12:22 pm, Larry wrote:
> Thanks David for your response.
>
> Could I get you to reply on the information found at this URL?
>
> http://support.microsoft.com/kb/898708/
>
> Thanks
> --
> Larry
>
>
>
> "David Wang" wrote:
> > On Jul 6, 1:32 pm, Larry wrote:
> > > Thank you David for your reply.
>
> > > We collect every request/response that comes to our web site and they are
> > > written into a session that we can replay back in a browser. The product is
> > > called Tealeaf. Anyway, from that session, we can look at all the header
> > > info, data, cookies, everything that is coming in as that request. Then as
> > > the response is generated, that then is attched to that request and we can
> > > see what is going back t the user.
>
> > > The reason I can see the http 100 is because of looking at specific user
> > > sessions when they have a problem. I can see the http 100 come in with a
> > > blank response other than that which IIS sends back and then no more requests
> > > come in. I compare that with the IIS logs - the http 100 does not record.
>
> > > I do not believe this is an IIS issue but I am at a loss explaining what is
> > > happening.
>
> > > Why wouldn't the browser be processing the response to a 100 request?
>
> > > Does the http 100 start at the browser? Isn't it asking if IIS is ready to
> > > process a request - thus a response to continue?
>
> > > Seems like a browser sending a 100 request should be processing the continue
> > > response. But here again, I'm not a pro at what all this really means.
>
> > > Thanks again for your reply.
> > > --
> > > Larry
>
> > > "David Wang" wrote:
> > > > Based on your description, I do not see anything wrong with IIS.
>
> > > > Can you describe why you think the user issue has to do with the "100
> > > > continue" response, and if it is the "100 continue", why the problem
> > > > is with IIS and not the remote client?
>
> > > > For example, your statement:
> > > > > The user sends the info, I can see the request hit 1 of our
> > > > > servers but the HTTP status of the request is 100. IIS
> > > > > responses appropriately to send the request, but the
> > > > > user says they never get back anything of the response for
> > > > > the quote. Our servers never get the request to process
> > > > > quote data.
>
> > > > You seem to indicate that "IIS responses appropriately to send the
> > > > request" but the HTTP status of 100 is unexpected. And that the user
> > > > never gets back the response and the server never get the request to
> > > > process quote data. Thus, you think that HTTP status 100 is the
> > > > "problem".
>
> > > > Actually, we will need the complete request from the client to
> > > > determine if the HTTP status 100 is expected or not. The HTTP/1.1 RFC
> > > > details what should happen, so we can easily look at the request and
> > > > determine who is at fault. You can't just look at client behavior to
> > > > determine if the 100 continue is expected or not.
>
> > > > For example, there are plenty of web clients who claim to handle 100
> > > > continue but cannot do it, so that would be a bug with the client.
>
> > > > At this point, it looks like the client chokes on 100 continue and
> > > > fails to post the actual quote request so the server does not process
> > > > data. If the request indicates that the 100-continue is ok, then this
> > > > would be a bug with the client. Maybe the clients are behind proxy
> > > > servers with bugs, etc.
>
> > > > I don't know of a way to "turn off 100 continue" on IIS6 because
> > > > HTTP.SYS will automatically send it at the right time when client
> > > > indicates it supports it. Your work-around for broken clients could be
> > > > to make your HTML FORMs use GET instead of POST.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Jul 6, 10:46 am, Larry wrote:
> > > > > We have been getting users of our web sites complain about not receiving
> > > > > responses to requests they send us. We are a property/casualty insurance
> > > > > company and all of our agents use the sites to process quotes, pay bills, all
> > > > > kinds of things.
>
> > > > > From time to time we will have a user send information let's say so we can
> > > > > quote an auto policy. (this happens with other type requests too) The user
> > > > > sends the info, I can see the request hit 1 of our servers but the HTTP
> > > > > status of the request is 100. IIS responses appropriately to send the
> > > > > request, but the user says they never get back anything of the response for
> > > > > the quote. Our servers never get the request to process quote data.
>
> > > > > Would someone give me a place to look why this occurring? The #s are
> > > > > increasing where this is happening.
>
> > > > > These are 2003 web server machines with the proper IIS and I have had this
> > > > > occur with users and browser versions 6.0 through 7. We are processing ASPX
> > > > > requests using .Net 1.1.
>
> > > > > The numbers of this type of incident are increasing. I see status 100
> > > > > requests come in but most of the time they do get the actual request then to
> > > > > process data. But sometimes we never see the final request.
>
> > > > > We do trap and save to sessions all requests/responses so I can look not
> > > > > only at what IIS is logging but also what the user is getting.
>
> > > > > Thank you very much. All help is greatly appreciated.
> > > > > Larry
> > > > > --
> > > > > Larry- Hide quoted text -
>
> > > - Show quoted text -
>
> > >Why wouldn't the browser be processing the response to a 100 request?
>
> > Because... maybe the browser has a bug?
>
> > HTTP 100 continue is an optimization. It is sent by the server to tell
> > the client to continue doing whatever it was going to do on that
> > request. It is used for sending entity body, in the following manner:
> > 1. Client sends request without entity body to server
> > 2. Server responds with 100 continue
> > 3. Client sends entity body to server
> > 4. Server response with status code of processing the request
>
> > Why is there 100 continue? Well, suppose the client is trying to make
> > a 4GB POST to a web application requiring authentication (suppose the
> > web application accepts large financial data files). Do you want the
> > request sequence to look like:
> > 1. Client sends request with 4GB entity body to server
> > 2. Server responds with 401 Authentication required
> > 3. Client sends request with authorization header and 4GB entity body
> > to server AGAIN
> > 4. Server responds with status code of processing the request
>
> > Why do you need to send at least 8GB of data to make a POST to an
> > authenticated applications?
>
> > With 100 continue, the client can send just the request header,
> > without 4GB entity body, telling the server "if you tell me to 100
> > continue, then I will send the 4GB entity body to you", and the server
> > can quickly tell the client "wait, you need to authenticate" or "go
> > ahead, send the entity body". The request sequence looks something
> > like:
> > 1. Client sends request with "expect:" header WITHOUT 4GB entity body
> > to server
> > 2. Server responds with 401 Authentication required
> > 3. Client sends request with "expect:" and authorization header
> > WITHOUT 4GB entity body to server
> > 4. Server responds with 100 continue
> > 5. Client sends the 4GB entity body to server
> > 6. Server responds with status code of processing the request
>
> > Notice that while there are 6 network request/response interactions
> > instead of 4 (which wastes negligible time and bandwidth), the second
> > version only transmits the 4GB entity body ONCE -- instead of
> > wastefully sending 8GB that takes non-negligible bandwidth and time.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -