Paul,
> > For "Transfer-Encoding" I think the correct way to deal with is to
> > split the
> > discussion into client and server. For the server side I agree with
> > you that
> > it is up to the container to provide this, since it is a simple
> > transports
> > problem but not related to the content resource itself; so GlassFish
> > should
> > provide this. For the client side I think that the Jersey Client API
> > should
> > support it, since there is nothing like a client container outside
> > of the
> > Java EE world.
> I have to double check, but i wonder if HttpURLConnection supports it.
> I don't think it does. I get the impression that TE is not supported
> that much. A browser such as Firefox does not send the TE header.
Actually it seems as if browsers (and caching proxies, BTW) are supporting
HTTP/1.1 only in a small subset, and there is a lot that our REST Client
could support that browser do not (so far). Let's do it! :-)
> So we could have a separate TE filter that is used internally (not
> publicly, as it should always be the last filter) to support decoding
> of response bodies (and could be configured to support encoding of
> requests).
Yes, but on the other hand, your idea with HttpUrlConnection is not so bad.
Why should it be the problem of the RESTful Client API, while actually it is
a problem of the transport? I mean, we could instead add TE support to
HttpUrlConnection, and provide an interface that the RESTful Client API can
access to deal with chunked transmission. It is much harder to do since we
must convince a lot of people at Sun to do provide that. So my proposal
would be to do what you said, and later convince Sun to improve the
HttpUrlConnection (and in turn move stuff from Jersey back into the JRE).
> > The Jersey Client should transparently support compressed
> > transports so the client application has nothing to deal with, and
> the
> > client application should have a means to participate in chunked
> > transports
> > to be able to present a progress bar and let the user cancel further
> > transportation (e. g. for video transfers, binary downloads, etc.).
> Yes, there is an issue for monitoring progress, cancelation is a good
> point.
The more video services stuff people will create, the more they will demand
monitoring and cancellation. For "simple" services where an entity is just a
few KB large, this is not much an issue. But I expect that there will a new
class of RESTful services in near future that provide large amounts of data
in on entity, like video streams, audio streams (instead of audio files), or
spatial information (maps) etc. So my proposal would be to provide support
an interface for monitoring and cancellation in JAX-RS 1.1 or 2.0. Certainly
Jersey can provide a solution much earlier, but for us as an ISV it is
always necessary to have a JSR that defines the standard.
Have Fun
Markus