You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Conan Wang (Commented) (JIRA)" <ji...@apache.org> on 2012/02/15 05:11:59 UTC

[jira] [Commented] (TS-1103) Traffic Server ESI plugin issues

    [ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208216#comment-13208216 ] 

Conan Wang commented on TS-1103:
--------------------------------

agree that gzip module of ESI is invalid for chrome.
                
> Traffic Server ESI plugin issues
> --------------------------------
>
>                 Key: TS-1103
>                 URL: https://issues.apache.org/jira/browse/TS-1103
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Plugins
>    Affects Versions: sometime
>         Environment: Newest trunk.
>            Reporter: Kevin Fox
>         Attachments: esi.patch
>
>
> Patch to fix:
>  * Makefile fix to add missing files.
>  * Change return code checking to match whats trunk trafficserver.
>  * Include missing header files.
>  * Fix c++ namespace issues.
>  * Work around strange name mangling/linking issue.
>  * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI.
> Things wouldn't work without it.
>  * Comment out a block of code that looked to be incorrectly handling
> EOF.
> After this, simply loading the plugin and setting response header X-ESI
> in apache httpd seems to work.
> A few further bugs I have bumped into that aren't addressed in this
> patch:
>  * It doesn't seem to parse gzip like it looks like it should. To work
> around, I had to disable it in apache httpd with "RewriteRule . -
> [E=no-gzip:1]"
>  * If the client requests gzip, the ESI processor will gzip the result.
> It works in firefox but is invalid in chrome. Pulling a dump with curl
> and running it through gzip --list shows it has the correct uncompressed
> size and compressed size. using zcat shows the correct data but has the
> warning: "invalid compressed data--length error". As far as I read the
> gzip spec though, the raw binary file looks valid to me. Not sure what
> this is. This can probably be simply disabled for now though.
> * esi:include is slightly broken. You get all the data back properly but
> sometimes the headers are sent prematurely with a Content-Length of
> 2**31-1. This causes clients to timeout and fail. I'm currently unsure
> how to fix this.
> I've tried a few of the more advanced esi features, including ensuring
> cookies make it back to the origin server and things seem to work good.
> So, once the above bugs are figured out (particularly the include one),
> I think it will be in pretty good shape.

--
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