[ 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