Skip to content

Proper mime negotiation in case of non-ajax request#7464

Closed
LTe wants to merge 2 commits intorails:masterfrom
LTe:mime_negotiation
Closed

Proper mime negotiation in case of non-ajax request#7464
LTe wants to merge 2 commits intorails:masterfrom
LTe:mime_negotiation

Conversation

@LTe
Copy link
Copy Markdown
Contributor

@LTe LTe commented Aug 28, 2012

Currently when client send request to rails with proper Accept header rails will return always HTML. When I need JSON or other format I can of course add .(:format) and rails will recognize this. Why is this the only option?

  • I do not want nor need to use :format in routes
  • I use jQuery.getJSON method with cross-domain option HTTP_X_REQUESTED_WITH is not set
  • There is a proper Accept header : application/json, text/javascript, */*; q=0.0
  • There is respond_to :json in controller definition
  • I use respond_with in action and give it an object that has to_json and as_json method implemented

When I ask for JSON rails should respond with JSON.

LTe added 2 commits August 28, 2012 12:06
Rails should recognize accept type and respond with proper format.
Request type should not matter. If a client asks for JSON, we deliver
him json.
Accept header is still valid when HTTP request is not XHR type
@josevalim
Copy link
Copy Markdown
Contributor

Browsers were used to send completely non-sense accept headers. For example, IE were used to ask for a png file with higher priority than text/html. We could eventually merge this pull request, but we would need to check first if browsers are sending proper accept headers, otherwise this change could make an application completely unusable.

@paneq
Copy link
Copy Markdown
Contributor

paneq commented Aug 28, 2012

Let's just say that we find out that IE6 is doing something stupid. Maybe we do not care as this browser is not supported in our project and we would like to drop workarounds in favor of following the http spec. What do you think about adding config for browser compatibility into rails ex.:

  config.browsers.ie = 8

This could mean that we want to support IE >= 8 and disable hacks for ie6 and ie7.

Could that be helpful ?

@mostlyobvious
Copy link
Copy Markdown

@drogus
Copy link
Copy Markdown
Member

drogus commented Aug 29, 2012

I'm fine with dropping support for IE6, as long as this behavior is extracted to a plugin - I don't like the idea of adding another setting and keeping such legacy things in core. This should be rather trivial to implement and we could point people to it in the CHANGELOG.

@rafaelfranca
Copy link
Copy Markdown
Member

👍 for the @drogus proposal

@josevalim
Copy link
Copy Markdown
Contributor

For the purpose of this discussion, this change will screw safari and chrome since they give higher priority to xml, according to this link:

https://developer.mozilla.org/en-US/docs/HTTP/Content_negotiation

So I really can't see how we can trust browsers accept headers.

@josevalim josevalim closed this Aug 30, 2012
@josevalim
Copy link
Copy Markdown
Contributor

Fun: We should probably convince browsers to send a X-Im-a-Browser: true header.

@steveklabnik
Copy link
Copy Markdown
Member

I really can't see how we can trust browsers accept headers.

:'( 😢

More about the situation than about your statement.

@mostlyobvious
Copy link
Copy Markdown

@josevalim According to https://bugs.webkit.org/show_bug.cgi?id=27267 Safari and Chrome should be OK.

The default accept header now mirror's FireFox'. The meaningful change is that 'text/html' is now preferred over 'application/xml'.

@LTe
Copy link
Copy Markdown
Contributor Author

LTe commented Oct 12, 2012

monkeys

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants