[
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
