Jan,
> > RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" chapter 3.6.1
> > "Chunked Transfer Coding" says "In other words, the origin server is
> > willing to accept the possibility that the trailer fields might be
> > silently discarded along the path to the client.", so I think it is
> > really acceptable that JAX-RS 2.0 does not support trailers.
>
> This note refers to intermediaries, not to the origin server HTTP
> connector.
Looking at the effective end-to-end result of the spec statement, it implies
that (even without any intermediate relays) it is valid that trailers get
lost in transmission. So, effectively, trailers cannot be used for anything
essential. In turn, this renders trailers to be not essential themselves,
hence, JAX-RS can omit support for them. That's what I wanted to say. If you
essentially need information, you must pass them as headers instead, as
anything else can be subject to potential loss due to the inherent nature of
http.
> Anyhow, it is no big deal, the use case simply popped up and we would
> have liked detect incolplete responses without embedding the check
> mechanism in the payload semantics. (We are sending plain CSV and if an
> exception occurs in the MBW writeTo the client will never know that it
> did not get all CSV lines.
As trailers may get trimmed by any relay (see above) you cannot be assured
to ever receive them, even if there is no error at all. I think there are no
other really stable working solutions to detect truncated payloads than
either sending a Content-Length header prefixing the plain content, or using
an inherently corruption-detecting payload format (like a ZIP).
Regards
Markus