[ 
https://issues.apache.org/jira/browse/TS-4766?focusedWorklogId=26660&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26660
 ]

ASF GitHub Bot logged work on TS-4766:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 19/Aug/16 16:23
            Start Date: 19/Aug/16 16:23
    Worklog Time Spent: 10m 
      Work Description: GitHub user shinrich opened a pull request:

    https://github.com/apache/trafficserver/pull/881

    TS-4766:  HTTP/2 frame corruption fix.

    Moved handler reset into the do_complete_frame_read worker.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/shinrich/trafficserver ts-4766

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafficserver/pull/881.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #881
    
----
commit bd69020f2febecd500edcafc9bff7ad2f0cdb126
Author: Susan Hinrichs <shinr...@ieee.org>
Date:   2016-08-19T16:20:23Z

    TS-4766:  HTTP/2 frame corruption fix.

----


Issue Time Tracking
-------------------

            Worklog Id:     (was: 26660)
            Time Spent: 10m
    Remaining Estimate: 0h

> HTTP/2 packet corruption introduced by TS-4717 fix
> --------------------------------------------------
>
>                 Key: TS-4766
>                 URL: https://issues.apache.org/jira/browse/TS-4766
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP/2
>            Reporter: Susan Hinrichs
>            Assignee: Susan Hinrichs
>             Fix For: 7.0.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We observed problems with large uploads over HTTP/2 via Firefox.  Tracked it 
> down to ATS sending a GOAWAY frame early because the frame appeared to be 
> corrupted.  The problem was introduced in the restructuring in TS-4717 to get 
> rid of the unbounded recursion.  The logic will return with one of two 
> handlers set.  One to deal with the case of starting to read a fresh frame 
> and another to deal with the case of finishing reading a partially read 
> frame.  There is a path where we finish reading a frame but don't reset the 
> handler to the new frame case.  When the next data arrives the wrong handler 
> starts reading it resulting in ATS thinking it has received a malformed frame.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to