On 10 December 2014 at 01:13, Stuart Douglas <sdouglas_at_redhat.com> wrote:
>
> > Because we cannot push POSTs and PUTs. We can push GETs and HEAD,
> maybe
> > even OPTION and these can be pushed in association with a POST (can't
> think
> > why a PUT would have push associates).
> >
>
> According to the spec I think it is just GET and HEAD, as the request must
> be both safe and cacheable, and OPTIONS is not cacheable. In practice GET
> is likely to be the only one that actually gets pushed.
>
>
There is a use-case for pushing HEAD requests. If the server is not sure
of the state of the client cache, but is also not in possession of the etag
or last modified date for a resource, then it can push a HEAD response to
inform the cache of the current state of the resource.
> I think that in this case if the user attempts to set the method to one
> that we know is explicitly disallowed by the HTTP2 spec we should throw an
> IllegalArgumentException.
>
>
The other option is to just support GET and HEAD and control which one with
a
setHeadRequest(boolean) method?
That removes the issue of throwing IAE for the arbitrary methods that might
get set on the push builder.
cheers
> Stuart
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.