[ https://issues.apache.org/jira/browse/TS-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Susan Hinrichs updated TS-3100: ------------------------------- Fix Version/s: (was: sometime) 5.3.0 > Extend the tr-pass window to allow malformed HTTP commands to be blind > tunneled > ------------------------------------------------------------------------------- > > Key: TS-3100 > URL: https://issues.apache.org/jira/browse/TS-3100 > Project: Traffic Server > Issue Type: Bug > Reporter: Susan Hinrichs > Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > Some servers abuse the HTTP protocol to implement services. ATS certainly > should not cache responses from malformed GET, POST, etc, it should get out > of the way if possible and pass the traffic along if the customer has marked > the port with tr-pass. > As the code is currently written, it will make the tr-pass blind tunnel > decision if the initial request does not parse. But if the initial request > does parse but the specification violation occurs later, the tr-pass decision > is not revisited. > One ISP using ATS has reported the following scenarios. The client sends a > well formed GET request. Then after the double carriage return line feeds, > it sends some additional text. The server interprets this as additional > requests for information. > Since the GET request was well formed, the connection is put on the HTTP path > and the extra data after the carriage return line feeds is stripped before it > is passed along to the server. > At a minimum, I want to revisit tr-pass decision after the header has been > parsed and the carriage return line feeds have been read in the GET case. If > the connection is not set to pipeline requests and there is more data in the > buffer, pass the connection on to be blind tunneled. > I plan to review the POST and PUT paths for other early options for tr-pass > evaluations too. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)