> Also, we're getting reports that IE clients on Windows consistently get
> 408s (server timeout) immediately from httpd. Some users with Safari and
> Firefox can see this problem occassionally, but MSIE triggers it a good
> portion of the time.
Is this only with https or also with http?
AFAIK, both https and http.
> Coupled with the EOR brokenness (infinite loop?), this sounds like the
> async-read code is severely busted. Either we should fix it, or we need to
> revert it. =)
Do we really have the async read code on trunk? Maybe I missed some commits, but
I thought that we only have the async write stuff in the trunk.
I thought it was the opposite, but I could very well be wrong.
I do know that the 408s are happening way down in the core - mod_proxy never even sees the requests that get a 408. So, anything that touched the reading of requests by the core is suspect. ;-)
> There are also still problems with proxy code corrupting data from the AJP
> side of things. See:
>
> https://issues.apache.org/jira/browse/INFRA-697
>
> for the infrastructure issue open for this. We were at 2.2.0 but the proxy
> code is just not working right. We confirmed network traces that Tomcat is
> sending the right bits back, but httpd is corrupting data near the end of
> the AJP send_body_chunk responses such that the client sees junk.
I saw in in jira ticket that you updated to trunk on ajax. Which revision is
running on trunk?
Whatever was there on Friday night. =)
'svn info' says the last change to trunk was 380878.
> My initial thought was that the we could have an issue with the transient
> buckets, but when I switched them to be a heap bucket - the corruption
> continued. Only when I did the SSL flush patch did the corruption largely
I don't think that transient buckets matter on prefork, but I think that they become
a problem with Event MPM and async write. So if you have this patch still at hand
I think it will be a good idea to commit it.
Agreed.
I will note that the only plausible way I can see that this corruption seems to happen is that AJP message buffer gets trounced some how. As far as I can tell, the HTTP protocol (i.e. C-L headers) are correct as-is the SSL - so the lengths are fine - but the buffer we write to the client is trashed. I'm not sure how though. Very weird. It happens with 2.2.0, so I know that this isn't a regression in trunk (like the 408s are). -- justin
