Ticket #801 (closed Defect: wontfix)

Opened 7 years ago

Last modified 7 years ago

REST APIs: content-less requests still need a Content-Type header

Reported by: jri Owned by: jri
Priority: Minor Milestone: Release 4.7
Component: DeepaMehta Standard Distribution Version: 4.6
Keywords: Cc: dgf, Malte
Complexity: 3 Area: Application Framework / API
Module:

Description

The DM REST APIs declare the consuming media type at class level:

@Consumes("application/json")

Thus all resource methods require a Content-Type: application/json request header in order to be triggered, even if the method does not consume any (message body) data at all. This makes the development of 3rd-party DM clients more difficult than necessary.

Without that Content-Type request header DM responds with 415 Unsupported Media Type as browsers set media type application/x-www-form-urlencoded in requests by default.

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to wontfix

After further investigation it became clear this is more a problem of Google Polymer as DM.

[...] as browsers set media type application/x-www-form-urlencoded in requests by default.

This is not fully true. Its rather Polymer's iron-ajax component which can't send a request without a Content-Type header. And its default value (application/x-www-form-urlencoded) for requests which don't have any content causes Jersey to emit this (bogus) warning:

WARNING: A servlet request, to the URI http://localhost:8080/core/topic/3249?include_childs=true,
contains form parameters in the request body but the request body has been
consumed by the servlet or a servlet filter accessing the request parameters.
Only resource methods using @FormParam will work as expected. Resource methods
consuming the request body by other means will not work as expected.

To suppress this unwanted warning, in case of a Polymer based DM weclient it must send application/json as content type anyway. The original issue can't be fixed.

Note: See TracTickets for help on using tickets.