[jira] [Updated] (TS-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1118: -- Fix Version/s: (was: 3.1.4) 3.3.0 Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. -- Key: TS-1118 URL: https://issues.apache.org/jira/browse/TS-1118 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.0 I'd like to make the core simpler, and more efficient, dealing with the cache keys. We have APIs today to modify the cache URL (lookup_url), but it's incredibly inefficient. I'll post more details on my ideas here when I have it all written down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1062) TSFetchUrl doesn't handle chunked encoding
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1062: Fix Version/s: (was: 3.1.4) 3.2.0 Not a regression; push out to 3.2. TSFetchUrl doesn't handle chunked encoding -- Key: TS-1062 URL: https://issues.apache.org/jira/browse/TS-1062 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Fix For: 3.2.0 If you use TSFetchUrl() to fetch a resource and the response comes back with chunked encoding, you are basically hosed. The caller never gets the SUCCESS event because FetchSM does not know how to decode the body. There's no content-length header and the origin server doesn't drop the TCP connection, so we just sit there waiting for the response to finish forever (well until the origin server drops the connection 10s later). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-975) server-transform.c broken
[ https://issues.apache.org/jira/browse/TS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-975: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving out to 3.3.0, please move back if you will have a new patch soon. There's no urgency here, we can land this any time you have the patch ready. server-transform.c broken - Key: TS-975 URL: https://issues.apache.org/jira/browse/TS-975 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.0 Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Priority: Minor Fix For: 3.3.0 Attachments: server-transform.c.diff While playing around with the server-transform plugin example, i noticed it was broken. After some meddling around, i got it working again. The changes are mainly that in some cases content-length was passed in network-byte order where it shouldn't be. Another fix was handling the TS_EVENT_IMMEDIATE event in transform_write_event(). i currently perform a TSVIOReenable(data-server_vio); on that event, and it seems to work. However, I'm not sure at all if that is the correct thing to do, so if anybody could help me out on that? :-). I have tested the changed code with a custom echo server, and confirmed that the plugin is actually sending and receiving to the echo server. I added the working code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1070:
Fix Version/s: (was: 3.1.4)
3.3.0
Out of time for 3.2 release; punt to 3.3.
replace and deprecate TSFetchURL()
--
Key: TS-1070
URL: https://issues.apache.org/jira/browse/TS-1070
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.3.0
TSFetchURL() has a number of shortcomings:
1. it's not cancellable
2. the event delivery is bizarre
3. it doesn't play nicely with the TSHttpHdr*() API.
I propose the following API changes:
typedef enum
{
...
TS_EVENT_FETCH_SUCCESS,
TS_EVENT_FETCH_FAILURE
} TSEvent;
TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
TSFetchWakeUpOptions);
TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
MIME headers. If the HTTP method in the HTTP header is not GET, and a error
will be reported.
The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
code. Hopefully there is some existing precedent to follow.
TSFetchResource() should be cancellable via the TSAction return value.
I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
eliminate this, I'd argue for a uint64_t flags parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1202) install traffic_shell man/doc pages in a more appropriate location
[ https://issues.apache.org/jira/browse/TS-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255935#comment-13255935 ] Leif Hedstrom commented on TS-1202: --- Yeah, I agree with Arno, why does the cache have to move? install traffic_shell man/doc pages in a more appropriate location -- Key: TS-1202 URL: https://issues.apache.org/jira/browse/TS-1202 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.4 Reporter: Igor Brezac Assignee: Igor Galić Priority: Minor Fix For: 3.1.4 Attachments: doc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving out to 3.3.0, please move back if there will be a fix soon for v3.1.4. Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.0 When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1202) install traffic_shell man/doc pages in a more appropriate location
[ https://issues.apache.org/jira/browse/TS-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256046#comment-13256046 ] Igor Galić commented on TS-1202: committed with the suggested changes to 574d45a6c494ab51197bb984e9142e7204841b1b This: http://sprunge.us/OMZY has the same adaptation for all other layouts. If you approve, I'll commit that as well install traffic_shell man/doc pages in a more appropriate location -- Key: TS-1202 URL: https://issues.apache.org/jira/browse/TS-1202 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.4 Reporter: Igor Brezac Assignee: Igor Galić Priority: Minor Fix For: 3.1.4 Attachments: doc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1202) install traffic_shell man/doc pages in a more appropriate location
[ https://issues.apache.org/jira/browse/TS-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256162#comment-13256162 ] Igor Brezac commented on TS-1202: - It works for me. I suggest you change datadir: /var/cache+, at least to make it correct. ATS does not make use of it. install traffic_shell man/doc pages in a more appropriate location -- Key: TS-1202 URL: https://issues.apache.org/jira/browse/TS-1202 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.4 Reporter: Igor Brezac Assignee: Igor Galić Priority: Minor Fix For: 3.1.4 Attachments: doc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
