You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "William Bardwell (JIRA)" <ji...@apache.org> on 2011/08/03 17:57:27 UTC
[jira] [Created] (TS-900) TSHttpTxnNewCacheLookupDo (experimental)
breaks requests to origin server
TSHttpTxnNewCacheLookupDo (experimental) breaks requests to origin server
-------------------------------------------------------------------------
Key: TS-900
URL: https://issues.apache.org/jira/browse/TS-900
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: William Bardwell
Priority: Minor
When I try to use the experimental API TSHttpTxnNewCacheLookupDo() it causes the requests to the origin server to use the port out of the cache url which is wrong, and the supplied url might not even be a valid url, it is just a cache key. So I think that the implementation of that function should not reset the client request url.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-900) TSHttpTxnNewCacheLookupDo (experimental)
breaks requests to origin server
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-900:
-----------------------------
Fix Version/s: 3.1.0
Assignee: Leif Hedstrom
> TSHttpTxnNewCacheLookupDo (experimental) breaks requests to origin server
> -------------------------------------------------------------------------
>
> Key: TS-900
> URL: https://issues.apache.org/jira/browse/TS-900
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: William Bardwell
> Assignee: Leif Hedstrom
> Priority: Minor
> Fix For: 3.1.0
>
> Attachments: lookupdo.diff
>
>
> When I try to use the experimental API TSHttpTxnNewCacheLookupDo() it causes the requests to the origin server to use the port out of the cache url which is wrong, and the supplied url might not even be a valid url, it is just a cache key. So I think that the implementation of that function should not reset the client request url.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-900) TSHttpTxnNewCacheLookupDo (experimental)
breaks requests to origin server
Posted by "William Bardwell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Bardwell updated TS-900:
--------------------------------
Attachment: lookupdo.diff
Don't copy new url into the client request (and this patch, plus calling TSHttpTxnSecondUrlTryLock() got things to work right for me, which means that I could get a second cache lookup, but requests still went to the origin server as determined by the state before calling either API, they were just cached under the new cache key.)
> TSHttpTxnNewCacheLookupDo (experimental) breaks requests to origin server
> -------------------------------------------------------------------------
>
> Key: TS-900
> URL: https://issues.apache.org/jira/browse/TS-900
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: William Bardwell
> Priority: Minor
> Attachments: lookupdo.diff
>
>
> When I try to use the experimental API TSHttpTxnNewCacheLookupDo() it causes the requests to the origin server to use the port out of the cache url which is wrong, and the supplied url might not even be a valid url, it is just a cache key. So I think that the implementation of that function should not reset the client request url.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira