Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Jetty respond with status 200 instead of 304 while using Servlet 4.0 PushBuilder #801
Because the bug tracking system says:
I just want to file in the issue this way.
I think the server (jetty 9.3.9-M1) does not accept the RST_STREAM command after the PUSH_PROMISE has been sent, because the client status code is always 200 instead of 304 for the pushed resource after the second request to the index page. So the resource is always pushed instead the client side cached one is used.
More information and a test case:
changed the title from
Jetty respond with status 200 instead of 304 while using http2
Jetty respond with status 200 instead of 304 while using Servlet 4.0 PushBuilder
Aug 4, 2016
Cannot reproduce. It's not clear what exactly the problem is, neither here nor in the StackOverflow page.
A resource that is being pushed always has a response code of 200.
The browser controls whether the server responds with a 304 (or pushes) by sending the conditional headers such as
Closing this issue.
If you have more information, we need exact reproducible steps, what is your expectation and what you get instead.
That is exactly what is not happening in my demo project I linked in the issue.
After the second request the server should not send the resource again with 200 (push), but for me it does.
It should avoid pushing with a 304.
Here is a screenshot of the second request to the index page. The server pushes the resource again.
Also Chrome is listing a push:
Maybe there is something wrong with the request headers to avoid pushing again?
kind regards and thanks a lot for your time!
The steps to reproduce it:
@klopfdreh I think there is a misunderstanding of what the push APIs do. Right now, they just push.
The logic of whether the request is conditional (i.e. contains headers such as
See for example how it has been implemented in Jetty's https://github.com/eclipse/jetty.project/blob/jetty-9.3.11.v20160721/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/PushCacheFilter.java[PushCacheFilter].
You should implement this logic in your
If you do, can you report back if it worked as expected ?
Hi @sbordet ,
first of all thanks for the clarification - great to get help in this issue here!
The implementation of Apache Wicket in this case is rather easy. The PushHeaderItem is created when the initial request to index page is going to be performed at this place:
At this time I don't know if the client is going to send the corresponding header for the resource (If-Modified-Since), because it is the request for the index page.
So if the response of the index page is send to the client and it does not received the resource previously via push (in the renderHead) I thought the client is going to request the resource as usual without the benefit of the push API, because it reads the link tag and perform an additional request.
I hope I could explain my trouble with it.
@klopfdreh I don't think you have this right.
The first time the client requests
The second time, the client requests
I don't know Wicket, but the logic to check conditional headers should be put in
Hi @sbordet ,
I changed the code in that way:
This results in the following behavior:
So the framework decides now when to push the resource and when it is better to save bandwidth. What do you think about that solution?
Anyway thanks a lot for the great help! If this implementation is ok I am going to apply the changes to the experimental project of http://wicket.apache.org/ and update the documentation https://ci.apache.org/projects/wicket/guide/8.x/guide/http2push.html soon.
@klopfdreh looks good to me.
Out of curiosity, and related to #193, would you prefer to add a
You would maintain the logic related to
Hi @sbordet ,
is this preload also working for a response composed via the servlet output stream? I ask because the response is no static resource file. Apache Wicket aggregates html files / the corresponding classes and the header items are rendered dynamically into the aggregated content.
Another question: How is PushBuilder / preload working together - does the server ensure that the resource is not pushed twice?
kind regards and thanks for having a look at the implementation.
Note that this is not yet implemented (hence #193).
Wicket will aggregate secondary resources, but eventually it will send just one response per primary resource. The headers on that response are important, there you want to add the
How the actual response content is composed by Wicket would be irrelevant, only the headers matter.
I had a look at the existing classes and it could be implemented with this class:
MetaDataHeaderItem.forLinkTag("preload",<url>); instead of CssHeaderItem
and the URL can be rendered with: