openresty+nginx erased my ETag when gzip enabled. how can I prevent this ?

[Payne Chu]

Hi, I'm trying to implement conditional GET base on ETag. But nginx will erased my ETag when the request Accept-Encoding set to gzip. Any ways to prevent this?

---

content_by_lua '

  ngx.header.etag = 'hello'

  ngx.say('hello')

';

curl -i -X GET http://localhost/                                             -> the etag appear properly

curl -i -X GET http://localhost/ -H "Accept-Encoding: gzip"     -> the etag gone

[Yichun Zhang (agentzh)]

Hello!

On Tue, Aug 13, 2013 at 8:58 PM, Payne Chu wrote:
> Hi, I'm trying to implement conditional GET base on ETag. But nginx will
> erased my ETag when the request Accept-Encoding set to gzip. Any ways to
> prevent this?
>

There's not much that we can do on the ngx_lua module side.

You need to patch the standard ngx_http_gzip_module (in the nginx
core) and makes it not clear the etag header if certain condition is
met (like if it is a weak etag). See the discussion in the following
thread on the nginx mailing list:

http://forum.nginx.org/read.php?2,240120,240120

Regards,
-agentzh

[Payne Chu]

thanks agentzh,

that's also how I do now :)~

[jijilu]

hello

I certainly agree that nginx supports gzip compression for *responses*. And it's great at that :)

But I haven't seen the gzip module do *decompression* for *requests*.

That is, if a request body is compressed (say a POST of a large request containing some client data which is compressed, including *request* header Content-Encoding: gzip), does nginx support decompressing that request before handing the (now decompressed) request to some backend server?

or, to use the http://math2.org/luasearch/zip.html#zip_open maybe need many temp files?

@jijilu

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[jijilu]

hello

I certainly agree that nginx supports gzip compression for *responses*. And it's great at that :)

But I haven't seen the gzip module do *decompression* for *requests*.

That is, if a request body is compressed (say a POST of a large request containing some client data which is compressed, including *request* header Content-Encoding: gzip), does nginx support decompressing that request before handing the (now decompressed) request to some backend server?

or, to use the http://math2.org/luasearch/zip.html#zip_open maybe need many temp files?

@jijilu

On 2013-8-16, at 下午2:37, Payne Chu <payn...@gmail.com> wrote:

[Yichun Zhang (agentzh)]

Hello!

On Tue, Aug 20, 2013 at 10:33 PM, jijilu wrote:
>
> But I haven't seen the gzip module do *decompression* for *requests*.
>

No, it doesn't. The standard gzip module is an output filter module
which works on responses only.

> That is, if a request body is compressed (say a POST of a large request
> containing some client data which is compressed, including *request* header
> Content-Encoding: gzip), does nginx support decompressing that request
> before handing the (now decompressed) request to some backend server?
>

There is no native support for that in the Nginx core. But you can
easily use a bit of Lua to do the decompression yourself atop the
ngx_lua module:

http://wiki.nginx.org/HttpLuaModule

> or, to use the http://math2.org/luasearch/zip.html#zip_open maybe need many
> temp files?
>

You can certainly do in-memory decompression by a proper Lua binding
library for zlib, just as the standard ngx_gzip module that never
touches the file system. You don't have to use this zip_open thing.

Regards,
-agentzh