Hi Sergey,
Sergey Beryozkin-5 wrote
>
> UnpackerResource does not have any specific requirements about the
> incoming Content-Type, it has no specific @Consumes.
>
> 415 is returned if Content-Type is not supported but right now
> UnpackerResource has effectively @Consumes("*/*"). I would not be
> surprised if Jersey also assumed the default wildcard, otherwise, given
> that UnpackerResource does not have explicit @Consumes, it would not be
> possible to post/put to it with Jersey clients.
>
Yeah, what's weird is that Jersey didn't allow through the request if you
specified "xxx/xxx" as the Accept header (via a call to .accept("xxx/xxx")
which our tests used to do. Maybe the test was more exposing a functionality
of Jersey than anything else, but I have to ask whether or not that's the
correct
functionality in general (which it kind of seems like it should be).
For example there is probably a set of known media types that are the IANA
types and if it's not in that list, then maybe it should 415, dunno...
Sergey Beryozkin-5 wrote
>
> "xxx/xxx" is a valid MediaType format so CXF parses it and lets through.
> I think it really boils down to whether "xxx/xxx" can be treated as a
> valid media type or not. We can add a check for "xxx/xxx" but then
> someone will set "text/123" - that is acceptable enough but I guess not
> something the tika server wants to accept :-)
>
True, good point. In fact, what we ought to do with both communities is
to inject Tika in there :) and to use Tika for detection and then drive
what we do in CXF from there (and thus in tika-server). Cross fertilization
of projects!
:)
Sergey Beryozkin-5 wrote
>
>> I guess I can update UnpackagerResource to guard against this and throw
>> HTTP
>> 415 itself, but it seems a bit intrusive and I was really hoping for more
>> of a seamless
>> Jar/Maven drop in fix.
>
> I think the proper fix is to explicitly list supported content-types,
> using wildcards when possible, example image/*, or a/b+*, etc
>
One other question I had though in this situation. It seems like CXF breaks
the incoming
InputStream if I specify "xxx/xxx". For example, Paul and I have tested,
specifying
a *known* Accept type, with the same stream and the Content-type:
application/msword,
and we have seen the request go through via CXF and Tika parses the stream
correctly
using its AutoDetectParser. Now, if we change the Content-type to "xxx/xxx",
then Tika
and its AutoDetectParser get the stream, but it appears to have been
changed. Is
CXF changing the InputStream or defaulting to a different encoding or
whatever? It seems
like if CXF is going to let through "xxx/xxx" and then the stream gets to
Tika, instead of
500 like we're getting in the test415 right now, we should be getting HTTP
200 OK at
the very least, which we do get if we change the Content-type to something
with the same
encoding as the input stream, in which case it looks like CXF doesn't modify
the stream.
For example, we tried changing Content-type to application/json just to see
what would
happen on test415, and that returned a 204 error.
Thoughts?
Cheers,
Chris & Paul
--
View this message in context:
http://cxf.547215.n5.nabble.com/TIKA-593-odd-behavior-related-to-CXF-JAX-RS-services-and-415-Http-response-codes-tp5600131p5600648.html
Sent from the cxf-user mailing list archive at Nabble.com.
