sc-status = 400 sc-win32-status = 64 What causes this?

I have a user posting to a page. They are going fine, even posting on the
page. At a particular point, they click a button to do a post and the
browser just hangs. When I look in the W3SVC1 log file, I see:
2005-07-28 14:28:52 10.28.98.130 POST
/GPCStoreFront/WebForms/PartInquiry.aspx - 80 - 10.120.198.2
Mozilla/4.0+(compatible;+MSIE+5.5;+Win32) 400 0 64



If I look in the HTTPERR log file, I see the related entry:

2005-07-28 14:28:52 10.120.198.2 20689 10.28.98.130 80 HTTP/1.0
POST /GPCStoreFront/WebForms/PartInquiry.aspx - 1 Timer_EntityBody
DefaultAppPool



My understanding is the 400 means bad request and that the 64 means "The
specified network name is no longer available.". What causes this?

And according to MS, the Timer_EntityBody means:

"The connection expired before the request entity body arrived. When it is
clear that a request has an entity body, the HTTP API turns on the
Timer_EntityBody timer. The limit of this timer is initially set to the
ConnectionTimeout value (normally 2 minutes). Each time another data
indication is received on this request, the HTTP API resets the timer to
give the connection an additional 2 minutes (or whatever is specified in
ConnectionTimeout)."



What does all this mean? Three weeks ago, the user was not having this
problem and now they are. I believe this is an environmental/network
problem because I don't have it. I can do the exact same functionality they
are and mine works fine. I also have a handful of other users doing this
exact same functionality and it works just fine for them too. Also, this
post never makes it back to my asp.net code.

Any help would be appreciated.

Thanks.

Re: sc-status = 400 sc-win32-status = 64 What causes this?

Are you running on Windows Server 2003 SP1?
Are you all using the same browser client or different?

I am suspecting that the browser clients are sending slightly different type
of POST request, and one of them is causing problems.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Joe Rattz" wrote in message
news:eoaOIXGlFHA.3372@TK2MSFTNGP10.phx.gbl...
I have a user posting to a page. They are going fine, even posting on the
page. At a particular point, they click a button to do a post and the
browser just hangs. When I look in the W3SVC1 log file, I see:
2005-07-28 14:28:52 10.28.98.130 POST
/GPCStoreFront/WebForms/PartInquiry.aspx - 80 - 10.120.198.2
Mozilla/4.0+(compatible;+MSIE+5.5;+Win32) 400 0 64



If I look in the HTTPERR log file, I see the related entry:

2005-07-28 14:28:52 10.120.198.2 20689 10.28.98.130 80 HTTP/1.0
POST /GPCStoreFront/WebForms/PartInquiry.aspx - 1 Timer_EntityBody
DefaultAppPool



My understanding is the 400 means bad request and that the 64 means "The
specified network name is no longer available.". What causes this?

And according to MS, the Timer_EntityBody means:

"The connection expired before the request entity body arrived. When it is
clear that a request has an entity body, the HTTP API turns on the
Timer_EntityBody timer. The limit of this timer is initially set to the
ConnectionTimeout value (normally 2 minutes). Each time another data
indication is received on this request, the HTTP API resets the timer to
give the connection an additional 2 minutes (or whatever is specified in
ConnectionTimeout)."



What does all this mean? Three weeks ago, the user was not having this
problem and now they are. I believe this is an environmental/network
problem because I don't have it. I can do the exact same functionality they
are and mine works fine. I also have a handful of other users doing this
exact same functionality and it works just fine for them too. Also, this
post never makes it back to my asp.net code.

Any help would be appreciated.

Thanks.

Re: sc-status = 400 sc-win32-status = 64 What causes this?

> Are you running on Windows Server 2003 SP1?

Yes I am.


> Are you all using the same browser client or different?

I am told the user is still using the same browser. I am taking this on
faith and have no way to verify it though.


> I am suspecting that the browser clients are sending slightly different
type
> of POST request, and one of them is causing problems.

Can you elaborate on this any? I notice in the log record from the HTTPERR
log file, that the post is HTTP 1.0, which looks a little funny. I turned
off HTTP 1.1 in my browser and mine still worked fine though. I will have
the user turn on their HTTP1.1 later today and see if that makes a
difference, but I am not optimistic that it will since it didn't effect me.

Any other ideas?

Thanks.


"David Wang [Msft]" wrote in message
news:e4ljfyLlFHA.572@TK2MSFTNGP15.phx.gbl...
> Are you running on Windows Server 2003 SP1?
> Are you all using the same browser client or different?
>
> I am suspecting that the browser clients are sending slightly different
type
> of POST request, and one of them is causing problems.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Joe Rattz" wrote in message
> news:eoaOIXGlFHA.3372@TK2MSFTNGP10.phx.gbl...
> I have a user posting to a page. They are going fine, even posting on the
> page. At a particular point, they click a button to do a post and the
> browser just hangs. When I look in the W3SVC1 log file, I see:
> 2005-07-28 14:28:52 10.28.98.130 POST
> /GPCStoreFront/WebForms/PartInquiry.aspx - 80 - 10.120.198.2
> Mozilla/4.0+(compatible;+MSIE+5.5;+Win32) 400 0 64
>
>
>
> If I look in the HTTPERR log file, I see the related entry:
>
> 2005-07-28 14:28:52 10.120.198.2 20689 10.28.98.130 80
HTTP/1.0
> POST /GPCStoreFront/WebForms/PartInquiry.aspx - 1 Timer_EntityBody
> DefaultAppPool
>
>
>
> My understanding is the 400 means bad request and that the 64 means "The
> specified network name is no longer available.". What causes this?
>
> And according to MS, the Timer_EntityBody means:
>
> "The connection expired before the request entity body arrived. When it is
> clear that a request has an entity body, the HTTP API turns on the
> Timer_EntityBody timer. The limit of this timer is initially set to the
> ConnectionTimeout value (normally 2 minutes). Each time another data
> indication is received on this request, the HTTP API resets the timer to
> give the connection an additional 2 minutes (or whatever is specified in
> ConnectionTimeout)."
>
>
>
> What does all this mean? Three weeks ago, the user was not having this
> problem and now they are. I believe this is an environmental/network
> problem because I don't have it. I can do the exact same functionality
they
> are and mine works fine. I also have a handful of other users doing this
> exact same functionality and it works just fine for them too. Also, this
> post never makes it back to my asp.net code.
>
> Any help would be appreciated.
>
> Thanks.
>
>
>
>
>

Re:sc-status = 400 sc-win32-status = 64 What causes this?

Hi Joe,

I have the same problem as yours.
I access my site at my home and all works fine.
When I try to access the site at work it hangs.
Did you find a solution to the problem?

Thanks,

Alexandre

Re: sc-status = 400 sc-win32-status = 64 What causes this?

Hi Joe,

I am experienceing the same problem at present and am interested if you ever
found out what was going on in this situation.

Any help would be very apprieciated - Cheers

Re: sc-status = 400 sc-win32-status = 64 What causes this?

On Jun 21, 5:58 pm, "patrick" wrote:
> Hi Joe,
>
> I am experienceing the same problem at present and am interested if you ever
> found out what was going on in this situation.
>
> Any help would be very apprieciated - Cheers


A 400 status code in the IIS Log file (vs HTTP.SYS log file) indicates
that the user-mode code, in this case ASP.Net, sent the 400. The
problem is with the request POST'd to the server, so it is either some
environmental problem in the network between client and server, or
something corrupting the request on the client itself. There is little
you can do on the server itself.


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