-
Notifications
You must be signed in to change notification settings - Fork 357
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
Corrupted POST data of type x-www-form-urlencoded after forwardOn404 #4867
Comments
The |
Hi, so, I'm really not able to reproduce this bug from 2021 exactly. Nevertheless, I found a related one that interferres with httpRequest.getInputStream() (same method that was called when creating EntityInputStream in Jersey, at least while POSTing x-www-form-urlencoded data): In short, Apache WicketFilter acts differently when just httpRequest.getInputStream() (without reading any data) has been called by a filter in advance. See details in readme.txt of my demo at https://github.com/gluser1357/jerseyissues/tree/issue-4867-wicket10 (runnable on Jetty 11 or Tomcat 10.1). Since the issue seems not related to Jersey as demonstrated in the demo I think this issue 4867 (originally created by us in 2021) can be closed (but please read upcoming comment before). |
Some news here: I posted the issue to the Apache Wicket Team and the guys were so kind and debugged it. The problem is actually not Wicket-related. In short:
See quickstarter and explaination here: https://issues.apache.org/jira/browse/WICKET-7071. This behaviour is not clear and not explained in the Servlet API docs (https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#when-parameters-are-available) but leads to errors e. g. if Jersey is used as servlet filter before other filters in a filter chain. One solution that would help me would be to make Jersey not calling getInputStream() in case of non-matching paths and FILTER_FORWARD_ON_404=true. E. g. by a lazy initialization of/within the wrapping EntityInputStream. Jersey team: Could you imagine such a lazy initialization of EntityInputStream which would avoid unneeded getInputStream() calls? UPDATE: For sake of completeness I added another example (quickstart) on github: https://github.com/gluser1357/jerseyissues/tree/getinputstream-and-form-data. It allows quickly to test
I'll further try to contact the other teams involved in this issue (Jetty, Tomcat, Jakarta spec). Maybe someone else wants to support here? UPDATE 2: Question: Can we alternatively workaround the whole issue by simply call getParameterMap() in a servlet filter before any other filters like Jersey come into play, or would we run in new trouble by doing this? See ReadParamsIfFormEncodedFilter code and comments in https://issues.apache.org/jira/browse/WICKET-7071 (in the comments). |
Actually, this issue is more general: Consider any Request that passes through Jersey-as-a-Filter, doesn't match, and is forwarded down the filter chain because of From the point of view of any downstream Filter or Servlet, this Request is already partially consumed. Any call to
On the other hand, calling The code looks like it maybe just isn't aware that the call to |
Great to hear about #5669! Thank you! |
Dear community, In the most recent jersey 2.35 I observed a possible bug that causes my application to fail:
After POSTing application/x-www-form-urlencoded content to my application AFTER applying a org.glassfish.jersey.servlet.ServletContainer filter along with forwardOn404, the first byte is always missing.
The problem seems to be caused by calling containerRequest.hasEntity() in WebComponent.filterFormParameters(). I guess that EntityInputStream.isEmpty() consumes one byte from the original request input stream to check if there is some content but, if content (one byte) is found, it does only push it back to EntityInputStream.input but not the original input stream of the servlet request that will be forwarded later on.
The jersey code around seems to be quite complex, so fixing won't be that easy for me. It would be great if you could fix this issue soon. Thank you.
(Meanwhile I'll try to add two more filters to circumvent the problem: The first one changes the content type to application/x-www-form-urlencoded_fixme and the second reverts it afterwards to application/x-www-form-urlencoded. This should hopefully work.)
The text was updated successfully, but these errors were encountered: