-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test Gzip + JSP #4520
Test Gzip + JSP #4520
Conversation
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
I have to move it to servlet 4.x because 2.5 is going to be deprecated. |
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
@senivam @jansupol what is your opinion on the commit: I found that in Weblogic, after the method HttpServletResponse#flushBuffer is invoked, it will refuse to add new headers in the response. It is possible that in other Servlet implementations it behaves similar. It is not the case of Jetty because I tested it is fine. I think it is possible to fix it in Weblogic instead of Jersey but probably it makes more sense to do this in Jersey because other implementations could also make problems. Let me know if you think in other way. |
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
@jbescos - just a question - why you do not use flush() method of the PrintWriter which actually wraps responseStream? |
I already tried it, but the problem is Weblogic creates internally a ServletOutputStream that wraps the original (weblogic.servlet.internal.ServletOutputStreamImpl). This wrapper will not accept more headers after flush. Then when ServletOutputStream#flush is executed, it is too late and it reach the status of not accepting more headers. |
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Adding a new example that tests JSP is GZipped with no issues.
Recently an issue was found in one servlet container, and this demonstrates the issue is not related to jersey.