[ https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26563&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26563 ]
ASF GitHub Bot logged work on TS-4733: -------------------------------------- Author: ASF GitHub Bot Created on: 18/Aug/16 02:51 Start Date: 18/Aug/16 02:51 Worklog Time Spent: 10m Work Description: Github user kshri23 commented on the issue: https://github.com/apache/trafficserver/pull/871 Yes, it does. I verified that by running the test submitted as part of that fix. Issue Time Tracking ------------------- Worklog Id: (was: 26563) Time Spent: 0.5h (was: 20m) > Cache writes fail when client requests IMS and server replies 200 > ----------------------------------------------------------------- > > Key: TS-4733 > URL: https://issues.apache.org/jira/browse/TS-4733 > Project: Traffic Server > Issue Type: Bug > Components: Core > Affects Versions: 6.2.0 > Reporter: Shrihari > Fix For: 7.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I think this issue happens because of a fix applied in issue TS-3828. > Imagine a case where the client requests 'IMS' and the cache doesn't have the > URL. In that case, we remove the IMS and send the request to origin server. > On receiving the response back, we send 304 to client and THEN write to cache. > However, when we build 304 response to client, we set > s->hdr_info.response_content_length = 0. > Since this call to build_response happens before we setup a tunnel to write > the data from 'http_server' to 'cache' we lose this information. > While setting up this tunnel, we rely on the above field to get the size to > write. However, since we have already zeroed it out we don't write anything > to the cache. > I verified that if I use length from the server_response instead of using the > pre-computed one, it solves the problem. Though, I am not sure if that should > be the solution. I am still looking into the code to see what is the right > thing to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)