Bug #70018 for Catalyst-Action-REST: Order of serializer type determination

Thu Aug 04 11:39:21 2011 rich.harkins [...] gmail.com - Ticket created

Subject:

Order of serializer type determination

It's possible I may be missing something but I've read through all the RFCs I could find on this topic and this seems to be a requirements bug. According to the docs and the source code (0.91), the serializer is chosen based on the incoming (request) content type at a higher priority than the Accept header to determine which serializer to use. In the case of POST, PUT, etc, the request content-type header will indicate the content type of the incoming post data, typically, "application/x-www-form-urlencoded" (RFC 2616 [1]), not the desired content type of the returned data. In essence, it's unclear whether the request content-type header should be consulted at all for selecting a serializer, but certainly it appears that the Accept header should win over it. With this in place, it is nearly impossible to request JSON data via Accept headers via Javascript without using the query string work-around. [1] http://tools.ietf.org/html/rfc2616#page-124

Thu Aug 04 11:43:15 2011 jshirley+cpan [...] gmail.com - Correspondence added

On Thu Aug 04 11:39:21 2011, rharkins wrote: Show quoted text

> It's possible I may be missing something but I've read through all the > RFCs I could find on this topic and this seems to be a requirements bug. > > According to the docs and the source code (0.91), the serializer is > chosen based on the incoming (request) content type at a higher priority > than the Accept header to determine which serializer to use. In the > case of POST, PUT, etc, the request content-type header will indicate > the content type of the incoming post data, typically, > "application/x-www-form-urlencoded" (RFC 2616 [1]), not the desired > content type of the returned data. In essence, it's unclear whether the > request content-type header should be consulted at all for selecting a > serializer, but certainly it appears that the Accept header should win > over it. > > With this in place, it is nearly impossible to request JSON data via > Accept headers via Javascript without using the query string work-around. > > [1] http://tools.ietf.org/html/rfc2616#page-124

To better understand, what you are saying is that you do a POST with x-www-form- urlencoded but wish to have a response of say application/json? (In this scenario, what I do is have my POST be of content-type: application/json and serialize the relevant form data into JSON)

Thu Aug 04 11:43:17 2011 The RT System itself - Status changed from 'new' to 'open'

Thu Aug 04 11:48:51 2011 rich.harkins [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #70018] Order of serializer type determination
Date:	Thu, 4 Aug 2011 11:48:40 -0400
To:	bug-Catalyst-Action-REST [...] rt.cpan.org
From:	Rich Harkins <rich.harkins [...] gmail.com>

This is exactly the case. I don't know of any stricture in HTTP (or REST) that would normally compel me to use the same data type between POSTed data and the desired return data. I could be wrong here, but the HTTP specs do not seem to indicate that the request Content-Type should be part of the serialization decision. However, I would understand if the $c->response->content_type, if specified, would overrule anything else (since that would be from the processing of the request). Thanks for the prompt reply! Rich On Thu, Aug 4, 2011 at 11:43 AM, J. Shirley via RT < bug-Catalyst-Action-REST@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=70018 > > > On Thu Aug 04 11:39:21 2011, rharkins wrote:

> > It's possible I may be missing something but I've read through all the > > RFCs I could find on this topic and this seems to be a requirements bug. > > > > According to the docs and the source code (0.91), the serializer is > > chosen based on the incoming (request) content type at a higher priority > > than the Accept header to determine which serializer to use. In the > > case of POST, PUT, etc, the request content-type header will indicate > > the content type of the incoming post data, typically, > > "application/x-www-form-urlencoded" (RFC 2616 [1]), not the desired > > content type of the returned data. In essence, it's unclear whether the > > request content-type header should be consulted at all for selecting a > > serializer, but certainly it appears that the Accept header should win > > over it. > > > > With this in place, it is nearly impossible to request JSON data via > > Accept headers via Javascript without using the query string work-around. > > > > [1] http://tools.ietf.org/html/rfc2616#page-124

> > To better understand, what you are saying is that you do a POST with > x-www-form- > urlencoded but wish to have a response of say application/json? > > (In this scenario, what I do is have my POST be of content-type: > application/json and serialize > the relevant form data into JSON) > >