You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "vijaya bhaskar mamidi (JIRA)" <ji...@apache.org> on 2010/05/12 20:54:47 UTC
[jira] Resolved: (TS-167) Support InkHttpFetchPage(s) in the TS API
[ https://issues.apache.org/jira/browse/TS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
vijaya bhaskar mamidi resolved TS-167.
--------------------------------------
Resolution: Fixed
code checked in
> Support InkHttpFetchPage(s) in the TS API
> -----------------------------------------
>
> Key: TS-167
> URL: https://issues.apache.org/jira/browse/TS-167
> Project: Traffic Server
> Issue Type: New Feature
> Components: InkAPI
> Reporter: Sean Cosgrave
> Assignee: vijaya bhaskar mamidi
> Fix For: 2.1.0
>
> Attachments: FetchSM.cc, FetchSM.h, fp_fetch_diff.txt
>
>
> This is the original description from Anirban:
> There are quite a few people that are attempting to write plugins that download data from an origin server (or other
> HTTP sites) and then optionally modify the contents like the transformation plugins allow for.
> However, the downloading of the pages is cumbersome and a repeated task as this, should be wrapped in an API.
> The input into the function would be
> 1. provide the headers passed into YTS as part of the request
> - the header should obviously include the url to fetch
> 2. provide the moment when to wake up the plugin's continuation. Options include
> 0 - as soon as the request is made - no attempt is made to wait for the download to happen
> 1 - as soon as the headers are downloaded
> 2 - as soon as a portion of the message is downloaded
> 3 - after the full download is complete
> 3. ability to not cache the data (optional) (only used if one would like to override the data
> 4. ability to not run plugins (optional)
> The output of the function would be
> 1. for each of the results
> - error codes that define the download status of each of the requests
> - IOBuffer ptr (or char*) to the results (the caller of the fxn has to release references to the IOBuffers or if char* is used free the chunk)
> - time to download each object (not so critical)
> Note: This fxn doesnt support streaming the answer back to the requesting client.
> The fetches should be asynchronous and simultaneous.
> A possible model would be to have the user call INKHttpFetchPages which then in turn calls INKHttpFetchPage per request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.