[
https://issues.apache.org/jira/browse/TS-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434850#comment-13434850
]
Kit Chan commented on TS-1249:
------------------------------
Thanks so much for your time to try these changes out.
#1
> I think that turning off PORT support should be a runtime or compile time
> option.
Item #4 in the "Description" is not really about supporting "POST" or not.
Specifically speaking, the ESI plugin has an internal mechanism that can try to
cache a more efficient version (called packed node in the code) of the ESI
response instead of the raw text. The hope, I think, is to make parsing much
easier for subsequent requests. The mechanism works like this
a) Determine that the ESI response has the proper cache control header and is
cacheable
b) Issue a internal "POST" request to the same URL with the same requests
headers. The post data is the packed node version of the ESI response
c) Intercept this internal request and replace the existing cache with it.
I find this mechanism extremely hard to get to work. So I turn if off
completely. It is also later on found to be a incorrect mechanism, too, in
yahoo!. The mechanism does not take into account that key for HTTP cache can be
changed with the Vary header in the response.
#2
> The second patch looks reasonably straight forward. There's one place where
> code is commented out with no explanation ... could you add some explanatory
> comments to these changes?
The commented out code is , i assume u mean, in the fetcher. These are the
lines. Right?
//if (Utils::areEqual(header.name, header.name_len,
// TS_MIME_FIELD_ACCEPT_ENCODING,
TS_MIME_LEN_ACCEPT_ENCODING)) {
// return;
//}
These lines are removing "Accept-Encoding" from the requests that the ESI
plugin sent based on ESI include in the ESI response.
Essentially they are stopping the ESI include from using gzipped for the
response. Commenting this out give this choice back to user.
User can choose whether to have Accept-Encoding header or not in his original
request and the ESI include will also be fired with the header if present.
Do let me know if you have any questions. Thanks.
> More Traffic Server ESI plugin issues
> -------------------------------------
>
> Key: TS-1249
> URL: https://issues.apache.org/jira/browse/TS-1249
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
> Affects Versions: 3.0.4
> Reporter: Kit Chan
> Assignee: James Peach
> Fix For: 3.3.1
>
> Attachments: git.dff, ts3.1.4.git.diff
>
>
> Is the current ESI plugin actually working? I saw TS 1103 and it is closed so
> I thought it is working. When I tried to compile it and make it work with
> traffic server 3.0.4, I got some problems. Even when i manage to compile it,
> the runtime is not actually working, too.
> So i decided to try to fix it. Here are the list of problems I find and fix.
> 1) Some "if" statements are checking whether the TS functions are returning 0
> or not but actually we should check against TS_SUCCESS or
> TS_ERROR
> 2) TSFetchUrl is still requiring ip and port as parameters so we need to pass
> them in
> 3) VConnWrite() should use INT64_MAX instead of INT_MAX. This is causing the
> ESI template with ESI include to return with a 2^32 -1 content legnth and
> causing the client to hang till timeout.
> 4) There is a mechanism to cache a parsed version of ESI template through a
> POST request internally but I find it hard to get it working. I can't get my
> ESI template with a valid cache control header to get properly cached in ats
> (which is somewhat useful to what i do). So I try to disable that.
> My fixes for #4 is quite hacky and there are actually lots of things we don't
> need if we don't do the internal POST
> request.
> The plugin seems to work well. I tested with ESI try/attempt/except syntax in
> my ESI response. I tested with multiple ESI includes. I tested with cache
> control header added for the ESI response so that I get the ESI Response
> cached in ats and subsequent requests will simply get the ESI response from
> cache instead of OS server. Gzip is also working, too.
> Any comments or reviews?
--
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
