Allow compression to be disabled in self-hosted

[rojosinalma]

Hello! I'm a dev using the gateway in a self-hosted environment (well actually in an EC2 machine in AWS), but I mean not running it as a service from Portkey.

Currently I'm having issues with the compression of requests, the gateway is basically using compression for every request unless its running on lagon or workerd. As per the code declares:

gateway/src/index.ts

Lines 35 to 38 in 8f60b16

	const runtime = getRuntimeKey();
	if (runtime !== "lagon" && runtime !== "workerd") {
	return compress()(c, next)
	}

I would prefer if compression is present only if there's a header in the request or alternatively provide an env var that allows to switch it off completely. I think the former would be a better option since it allows traffic control on a per-request basis.

[roh26it]

Hi @rojosinalma,

Thanks for reaching out!

The gateway respects the Accept-Encoding header in the request. You can try setting it to identity in your requests to disable compression.

Let me know if you need more help

[rojosinalma]

Thanks for explaining, but I still don't fully understand how is what you mentioned going to bypass what's hardcoded in the block I posted.

Could you give me more information please?

[VisargD]

Hey @rojosinalma - The compress middleware code that you have pointed out is written in a way that it will only do compress if the Accept-Encoding has a compression technique mentioned in it or if the code itself imposes a compress technique. In the case of gateway, we have not mentioned any compression technique, so it will rely on Accept-Encoding header. So if you send Accept-Encoding as identity, then it will not apply any compression on response. I hope this helps.

[rojosinalma]

Could you point me to the docs where this is explained? I only found this: https://hono.dev/middleware/builtin/compress But that doesn't mention anything about the header containing identity or anything.

…

On Sun, Mar 3, 2024, 13:14 Visarg Desai ***@***.***> wrote: Hey @rojosinalma <https://github.com/rojosinalma> - The compress middleware code that you have pointed out is written in a way that it will only do compress if the Accept-Encoding has a compression technique mentioned in it or if the code itself imposes a compress technique. In the case of gateway, we have not mentioned any compression technique, so it will rely on Accept-Encoding header. So if you send Accept-Encoding as identity, then it will not apply any compression on response. I hope this helps. — Reply to this email directly, view it on GitHub <#231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF6SA7JXU6MQMUEO4JR3YDYWMH2BAVCNFSM6AAAAABEB37ZU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGE2DANZRGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[VisargD]

The same link that you have shared contains this info: https://hono.dev/middleware/builtin/compress#options

The compression scheme to allow for response compression. Either gzip or deflate. If not defined, both are allowed and will be used based on the Accept-Encoding header. gzip is prioritized if this option is not provided and the client provides both in the Accept-Encoding header.

Here it is mentioned that Accept-Encoding header is used to determine the type of response compression. So if you do not send it, then hono will not compress it.

Regarding the identity value for accept-encoding, its a HTTP standard that is also mentioned in MDN web docs. So you can either remove accept-encoding from request header or send it as identity to inform server to not apply the compression. Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding#identity

When you send the header as identity, the code that is written inside hono compress middleware will not find any encoding and gateway also does not pass any default encoding method, so it will skip compressing the response. Here is the code for hono compress middleware: https://github.com/honojs/hono/blob/main/src/middleware/compress/index.ts

[rojosinalma]

Thank you for the clarification.

…

On Sun, Mar 3, 2024, 17:28 Visarg Desai ***@***.***> wrote: The same link that you have shared contains this info: https://hono.dev/middleware/builtin/compress#options The compression scheme to allow for response compression. Either gzip or deflate. If not defined, both are allowed and will be used based on the Accept-Encoding header. gzip is prioritized if this option is not provided and the client provides both in the Accept-Encoding header. Here it is mentioned that Accept-Encoding header is used to determine the type of response compression. So if you do not send it, then hono will not compress it. Regarding the identity value for accept-encoding, its a HTTP standard that is also mentioned in MDN web docs. So you can either remove accept-encoding from request header or send it as identity to inform server to not apply the compression. Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding#identity When you send the header as identity, the code that is written inside hono compress middleware will not find any encoding and gateway also does not pass any default encoding method, so it will skip compressing the response. Here is the code for hono compress middleware: https://github.com/honojs/hono/blob/main/src/middleware/compress/index.ts — Reply to this email directly, view it on GitHub <#231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF6SA6T4T2Y4IKQYN6E6LDYWNFUHAVCNFSM6AAAAABEB37ZU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGIZDANBVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rojosinalma]

This issue is still present when using Gemini, even when adding the header I was instructed to add Gemini is failing because of compression. If I bypass the previously mentioned condition, the Gateway works.

Can you please add an option or give some alternative to completely disable it?

cc @VisargD @roh26it

[vrushankportkey]

@rojosinalma we recently made some updates to fix this. Can you please try again?

[rojosinalma]

At this point (4 months later) we already found a work around it on our own.
Could you describe what you changed?