You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "James Peach (Created) (JIRA)" <ji...@apache.org> on 2012/01/02 06:03:30 UTC
[jira] [Created] (TS-1070) replace and deprecate TSFetchURL()
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
Priority: Minor
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] [Assigned] (TS-1070) replace and deprecate TSFetchURL()
Posted by "James Peach (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Peach reassigned TS-1070:
-------------------------------
Assignee: James Peach
> 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.1.2
>
>
> 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] [Updated] (TS-1070) replace and deprecate TSFetchURL()
Posted by "James Peach (Updated) (JIRA)" <ji...@apache.org>.
[ 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-1070) replace and deprecate TSFetchURL()
Posted by "James Peach (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182335#comment-13182335 ]
James Peach commented on TS-1070:
---------------------------------
I'll take it.
> 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.1.2
>
>
> 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] [Updated] (TS-1070) replace and deprecate TSFetchURL()
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-1070:
------------------------------
Fix Version/s: 3.1.2
> 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
> Priority: Minor
> Fix For: 3.1.2
>
>
> 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-1070) replace and deprecate TSFetchURL()
Posted by "Leif Hedstrom (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181866#comment-13181866 ]
Leif Hedstrom commented on TS-1070:
-----------------------------------
Either of you care to provide a patch? :) If so, take the bug, and then reassign it to me when it's ready for review.
> 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
> Priority: Minor
> Fix For: 3.1.2
>
>
> 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] [Updated] (TS-1070) replace and deprecate TSFetchURL()
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-1070:
------------------------------
Fix Version/s: (was: 3.1.2)
3.1.3
Moving out to 3.1.3 for now.
> 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.1.3
>
>
> 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-1070) replace and deprecate TSFetchURL()
Posted by "Brian Geffon (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179761#comment-13179761 ]
Brian Geffon commented on TS-1070:
----------------------------------
I tend to agree that TSFetchWakeUpOptions could be thrown out, it's only AFTER_BODY or AFTER_HEADER, so if we support sending both GET and HEAD requests then we can eliminate this weird option and let the request type differentiate between wakeup options.
> 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
> Priority: Minor
>
> 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