Santiago Pericas-Geertsen

> In this case a user would likely never send a `Content-type` header for either of the GET requests, so I think it's unreasonable to ask developer to add `@Consumes("*/*")`...

If we can't find an elegant solution to this problem, we may need to defer this change until 4.0 and simply document the current behavior in more detail. Breaking lots...

> > But can we really do this? In order to know if the method has an entity we need to match it first. > > Is it any different...

I'd like to suggest that we revert this change in 3.1 and re-target it for 4.0 to avoid having to make the TCK changes, and to avoid any potential compatibility...

PR #1043

These are good point @NicoNes. We definitely need a clarification here and an understanding as to why implementations do not appear to honor the `getEntity()` semantics here. Any comments @jansupol?

I agree with @NicoNes interpretation of the Javadoc. I think it's important to convert this into actual use cases: (1) getEntity() -> InputStream (2) getEntity() -> InputStream, InputStream consumed, getEntity()...

@NicoNes Are you interested in submitting a PR that clarifies the `getEntity`, `readEntity` and `buffer Entity` docs and interactions? Looks like all these javadocs can use some tweaking to clarify...

@NicoNes Sorry, it's been a while. Could you clarify in (5) the state of `InputStream` returned by `readEntity(InputStream.class)`? Is it of any use to support that?

> Hey @spericas , > > Good catch. > > In (5), the `InputStream` is fully consumed (i.e inputStream.read()==-1) and also closed. So: > > (5) **readEntity(Foo.class) -> Foo, readEntity(InputStream.class)...