users@servlet-spec.java.net

[servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re: Removing headers from the response

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Sun, 4 Jan 2015 17:08:21 -0500 (EST)

----- Original Message -----

> From: "Greg Wilkins" <gregw_at_intalio.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Sent: Thursday, 1 January, 2015 9:47:40 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Removing
> headers from the response

> On 31 December 2014 at 20:22, Mark Thomas < markt_at_apache.org > wrote:

> > > Perhaps there needs to be some standards support for
>
> > > activating/delegating such concerns to the container?
>

> > I like it. Apart from compression, what other concerns did you have in
> > mind?
>
> There are a few protocol mechanisms that it is a little unclear at the moment
> if they are the responsibility of the container or the webapp, and I think
> with HTTP/2 there will be a few more. So it would be good for a webapp to be
> able to declare: yes/no/don'tcare for container support for:

> * Body compression

Would this just be something like Response.setBodyCompressionAllowed(true/false)?

> * Header compression (HTTP/2 only, where there are some optional ways to
> encode unknown headers that may affect security)

If we are going to expose this then do we also need to expose how the incoming request headers are encoded? In particular if a header was encoded with 'Literal Header Field Never Indexed'. Personally I am not really sure if this is necessary, as it will only really matter if someone is writing a servlet that acts as a HTTP2 intermediary, they will need to know if any incoming headers were encoded like this so they can encode the outgoing request headers the same way.

> * Expect 100 handling

I don't think that anything is really needed from an API perspective here, although it might be useful to specify how a container should handle this (also bear in mind that this is not relevant for HTTP2).

The way Undertow handles this is that we send the 100-continue response when the user first tries to read from the input stream. If the user sets a 417 response then we also add a Connection: close header at response commit time, as there is a potential race where a client may have decided to send the request anyway.

> * Use chunking or EOF for unknown response lengths

I have also seen cases where an application wants to be in charge of the chunking (in JRuby applications running on a servlet container, where the ruby code expects to have to handle the chunking itself).

Stuart

> *
> cheers

> --
> 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.