[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107114#comment-14107114
]
Alan M. Carroll commented on TS-2983:
-------------------------------------
The issue was the the IOBufferReader was initialized after data had arrived in
the IOBuffer. That can lead to dropped data depending on how much the client
sends initially. Moving the read init to the constructor instead of the event
handler fixes the problem. See the comments on MIOBuffer::alloc_reader for more
detail.
> request headers, http object corrupted in 5.0.x
> -----------------------------------------------
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.0
> Reporter: Sudheer Vinukonda
> Assignee: Alan M. Carroll
> Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=xxxxxxxxxxxxxxxxx;%20ypcdb=xxxxxxxxxxxxxxxxxx - NONE/- -
> {code}
> After a lot of debugging, figured that the request was getting corrupted even
> before remap and in fact, is being parsed incorrectly at the read request
> state. Further analysis lead me to the commit TS-2197 (commit
> 30fcc2b2e698831d1a9e4db1474d8cfc202818a3 in Oct'13), which has altered the
> way the request is read slightly. Reverting the commit seems to have fixed
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
