Allow _method override in GET requests? #312

grEvenX opened this Issue Oct 9, 2012 · 11 comments

4 participants


This issue is related to #70.
What I'm trying to create with FOSRestBundle is a fully RESTful/HATEOAS API applying best-practices in the API community.
I currently found myself having to struggle with the requirement to be able to communicate with this API from IE8/IE9.
The dillema is:

  • I am creating an API for our platform which means that there will be many different clients accessing it (including IE8/IE9)
  • We only want to support secure transport (so HTTPS)
  • IE 8/9 does not support CORS by xhr2, but needs to use something called XDomainRequest (which as far as my tests and research go does not support POST over HTTPS, only through HTTP)
  • XDomainRequest also does not allow for setting custom headers (so one can't set X-HTTP-METHOD-OVERRIDE header)

This means that I won't be able to POST/PUT/DELETE through IE8/9 and https to the cross-domain API.
Then I was thinking about another fallback using JSON-P.
But as probably most know, JSON-P is also only possible via GET request leading to the same situation.

I get the problem with caching and browsers, but the questions is if it needs to be possible to override _method in GET requests in order for having these kinds of APIs working at all in IE8/IE9?
Or does anyone see any solutions to this problem that I don't see?


This issue does perhaps belong to the Symfony project and not FOSRestBundle, but I guess this is of main concern to this project.


Yeah it probably belongs there, but it won't go through. You are not the first one requesting this feature, but it was always shoot down.


@mvrhov Where have this been discussed earlier, I just searched through the Symfony github repo but couldn't find any issue on the topic (only related topics)? On another note, have you experience with this issue yourself and do you know if there are any good alternative workarounds?


My PR was the first: symfony/symfony#1000, symfony/symfony#4202 is another one, but there are probably more.


An update on the issue, HTTPS POST requests from IE is indeed possible, however there's another bug in their implementation which I need to get around (Source

  1. Only text/plain is supported for the request's Content-Type header

In the original incarnation of the XDomainRequest object, we allowed specification of the Content-Type for a POST >request. It was pointed out that this violated our goal of emitting only requests that HTML Forms can issue, because >HTML Forms are limited to sending data in three different content types: text/plain, application/x-www-urlencoded, >and multipart/form-data. In particular, it was pointed out that some AJAX server libraries would blindly assume that if >they received a request with a SOAP or JSON Content-Type, then the client must either be trusted or Same Origin (because HTML itself previously offered no way to issue cross-origin requests with that Content-Type).

Unfortunately, when we fixed this problem in a later IE8 Beta, we went a bit too far; we restricted the content type to >text/plain but didn’t allow the caller to specify that the data was in application/x-www-urlencoded form. This is >problematic because server-side frameworks (e.g. ASP, ASPNET, etc) will only automatically parse a request’s fields >into name-value pairs if the x-www-urlencoded content type is specified.

To workaround this issue, server code that currently processes HTML Forms must be rewritten to manually parse the >request body into name-value pairs when receiving requests from XDomainRequest objects. This makes adding >support for the XDomainRequest object more difficult than it would be otherwise.

So basically I guess we can do without allowing GET request to support _method, just have to figure out how to cope with this text/plain sent as Content-Type. I think perhaps I'll write up a blog-post about all of these issues regarding creating a restful service which should also work with current generation browsers (after I've figured out the solutions to it).


Basically nothing new. M$ is still hampering the web development. 👎

FriendsOfSymfony member

ok .. so i guess this ticket can be closed?


@lsmith77 I see FOSRestBundle as a bundle that should help developers create best-practice based REST APIs (correct me if wrong). I think making sure the REST API is accessible from all clients (even flawed ones as MS IE) is of importance.
I agree with the Symfony devs that it seems like a poor choice to support overriding method in GET in this area as it's possible to use POST which is not considered "safe" as GET per RFC. There's howeve one remaining issue that needs to be dealt with in order for IE to work, which is to "force" how the POST request is handled by the server.
What's your thoughts:
1. Should I close this one and open a new issue with a request to override how Symfony parses the request body when no Content-Type is set from the client?
2. Should I close this one and open an issue on the Symfony project instead?
3. Is there no concern/interest for the issue, and I should just leave it to be an implementation I enable on my own services

FriendsOfSymfony member

Well in general the purpose of this bundle is to help build restful applications. it isnt so much about fixing broken clients, though I am not going to say flat out no since we all have to live in the real world and being restful isnt a dogma but just a way to solve real world problems. The issue with doing our own "fixes" is that they tend to break key assumptions which kind of brings down the entire house. So whenever doing anything like this it has to be well thought out and ideally be based on a popular solution to the same problem.

Have you looked at how the BodyListener works? maybe you can solve your issue by just registering a decoder?


You can use a CrossDomainRpc.

This works by submitting a form through an iframe to the server. The server detects the CrossDomainRpc, and sends back a specially crafted response, that redirects the client back to the origin url, along with the response data. Once returned, the parent window reads the returned data out of the iframe.

All you need for this is a custom listener which hooks into the kernel.request/kernel.response events to modify request, and response.

See for more info, and sample implementations.


@schmittjoh @lsmith77 thanks for the input, perhaps it's better to support something like this on the server-side and recommend using it on the clients. I found also which seems to be a good match.
I'm closing this one as it seems like the consensus is on not to do a hack to fix one specific browser's flaws.

@grEvenX grEvenX closed this Oct 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment