[
https://issues.apache.org/jira/browse/TS-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427853#comment-13427853
]
Kit Chan commented on TS-1249:
------------------------------
After using the plugin for a while in a few use cases, I find a few issues
1) Gzip - The ESI plugin will strip "Accept-Encoding" for all GET requests that
it needs to send for ESI Includes. So the origin servers will always serve the
response back uncompressed for these ESI include requests. To fix the problem,
we need to stop stripping "Accept-Encoding" for all GET requests for the ESI
Includes and then when those responses are coming back, we need to check the
"Content-Encoding" header. If it is "gzip", then we will do a gunzip on the
response before assembling the data back to the originating ESI response
document.
2) POST requests - A "Content-Length" header comes with POST request to specify
the length the data that is being posted. The ESI plugin will pass this header
to the GET request of the ESI include inside a ESI response. Some origin
servers are going to hang because it is expecting some data with a GET request
and a "Content-Length" header. So we need to strip in header of
"Content-Length" for all GET requests that the ESI plugin needs to send as
instructed by a ESI response document.
3) Range request - It really does not mix well with ESI. First of all, we can't
strip the "Range" header in the ESI plugin since we don't know if the response
is going to contain ESI markup or not. And if it doesn't, we surely want to
send the origin server partial content back. Currently ESI plugin will only
trigger processing for response with status 200. So a status 206 for partial
content from origin server will not trigger ESI processing even if there is
valid ESI markup in the response. The only real problem that we need to fix is
to stop the "Range" header from getting passed to the GET requests of the ESI
includes. So the fix is to strip "Range" header requests from ESI include GET
requests
I have my fixes checked into github. The diff can be found here -
https://github.com/shukitchan/trafficserver/commit/ea66048038a797d4558ca33bbcd8b84df2b3c810
> 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
> 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
