jax-rs-spec
  1. jax-rs-spec
  2. JAX_RS_SPEC-396

MediaType.isCompatible does not recognize media types with composite subtypes

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1
    • Component/s: model api
    • Labels:
      None

      Description

      application/xml+bar is compatible with application/xml+* but MediaType.isCompatible will return false on these types.

      The method will need to do one extra check, "|| typesAreEqual and bothSubTypesContainPlus, if yes - split both subtypes, the values before '+' must be equal, afterwards either equal or one of them is a wildcard".

      application/*+bar and application/xml+bar might also be checked - though the former case is probably more interesting/more real world one...

        Activity

        Hide
        Marek Potociar added a comment -

        Yes, this is a problem that we currently see too - except that we focus on a standard-supported solution where structured syntax name suffixes are applied to the end of an arbitrary media type/subtype, i.e. foo/bar+xml is compatible with application/xml (see also XML Media Types RFC-3023 ).

        We IMO also need to add support for defining entity providers support producing/consuming media types based on these structured syntax name suffixes. For example:

        @Produces("+xml", "application/xml", "text/xml")
        public class MyXmlWriter implements MessageBodyWriter {
           ...
        }
        
        Show
        Marek Potociar added a comment - Yes, this is a problem that we currently see too - except that we focus on a standard-supported solution where structured syntax name suffixes are applied to the end of an arbitrary media type/subtype, i.e. foo/bar+xml is compatible with application/xml (see also XML Media Types RFC-3023 ). We IMO also need to add support for defining entity providers support producing/consuming media types based on these structured syntax name suffixes. For example: @Produces( "+xml" , "application/xml" , "text/xml" ) public class MyXmlWriter implements MessageBodyWriter { ... }
        Hide
        beryozkin_sergey added a comment -

        Interesting, "+xml", I'd probably avoid having the shortcuts, though the spec may help the users and list the actual media types where 'xml' and be added to the main subtype...Interesting anyway,

        re, "foo/bar+xml is compatible with application/xml", can you link please to the actual test implying such two types are compatible ?

        Thanks

        Show
        beryozkin_sergey added a comment - Interesting, "+xml", I'd probably avoid having the shortcuts, though the spec may help the users and list the actual media types where 'xml' and be added to the main subtype...Interesting anyway, re, "foo/bar+xml is compatible with application/xml", can you link please to the actual test implying such two types are compatible ? Thanks
        Hide
        Marek Potociar added a comment -

        Have you checked the XML Media Types RFC-3023 ? That's where this compatibility is defined. Also RFC 6838, sect. 4.2.8 talks about this in general.

        Show
        Marek Potociar added a comment - Have you checked the XML Media Types RFC-3023 ? That's where this compatibility is defined. Also RFC 6838, sect. 4.2.8 talks about this in general.
        Hide
        Santiago Pericas-Geertsen added a comment -

        Support for these composite subtypes is also absent from our resource matching algorithm. We should address that in 2.1 as well.

        Show
        Santiago Pericas-Geertsen added a comment - Support for these composite subtypes is also absent from our resource matching algorithm. We should address that in 2.1 as well.
        Hide
        beryozkin_sergey added a comment -

        Indeed, while it appears that subtypes sharing the common type are compatible (ex, /v1+xml is compatible with /xml), it is not obvious the subtype alone can be used to judge on the compatibility, recall that we did not even agree that "text/xml" and "application/xml" were compatible.
        Either way, look forward to a proper discussion in due time

        Show
        beryozkin_sergey added a comment - Indeed, while it appears that subtypes sharing the common type are compatible (ex, /v1+xml is compatible with /xml), it is not obvious the subtype alone can be used to judge on the compatibility, recall that we did not even agree that "text/xml" and "application/xml" were compatible. Either way, look forward to a proper discussion in due time
        Hide
        beryozkin_sergey added a comment -

        And indeed, we probably do not want to do any assumptions for cases like "application/v1+xml" vs ""application/v2+xml""

        Show
        beryozkin_sergey added a comment - And indeed, we probably do not want to do any assumptions for cases like "application/v1+xml" vs ""application/v2+xml""
        Hide
        beryozkin_sergey added a comment -

        One more input: after naively implementing a subtype compatibility check like this: "/*+xml" == "/xml" I got one of the test failing, due to "application/xhtml+xml" becoming compatible with "application/xml"

        Show
        beryozkin_sergey added a comment - One more input: after naively implementing a subtype compatibility check like this: "/*+xml" == "/xml" I got one of the test failing, due to "application/xhtml+xml" becoming compatible with "application/xml"

          People

          • Assignee:
            Unassigned
            Reporter:
            beryozkin_sergey
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: