Support for compression of HTTP responses #61
Comments
|
thanks @danielwhite 👍 merges are done so should work if building from source, or it'll be in the next release! |
ian-kent
added a commit
to mailhog/http
that referenced
this issue
Oct 6, 2015
breaks event source, no obvious reason (possibly gzip writer closing when handler func returns, but preventing that didn't help) reopens mailhog/MailHog#61
|
compression seems to break the event source connection, taking it back out while I investigate |
|
Ouch. Sorry I didn't spot that. I'm happy to track down and fix the problem if nothing obvious has jumped out already. |
|
I haven't had a chance to look properly yet, it may well be an issue with goose rather than MailHog - but yeah I'd appreciate it if you do have time to investigate! |
|
Closing this. There are other issues here that suggest extracting out attachments that I think may be the better solution to the problem for now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We're using MailHog for testing in an environment where testers and deployments are geographically distributed.
When the inbox has more than 50 messages, then refreshing the inbox can result in a response that can be 10MB or more. With compression, this reduces the response for a full 50 messages to a few hundred KB.
While we could put MailHog behind a real web-server, this would be an extra complexity that detracts from it being a simple drop-in solution.
This issue is primarily for visibility, and the relevant pull requests to support this are:
The text was updated successfully, but these errors were encountered: