Databases
StackOverflow2013
Postsdbo
POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
    primarykey
    data
    text
    <p>In Rails 2.3.4, the way <code>Accept</code> headers are handled has changed:</p> <p><a href="http://github.com/rails/rails/commit/1310231c15742bf7d99e2f143d88b383c32782d3" rel="nofollow noreferrer">http://github.com/rails/rails/commit/1310231c15742bf7d99e2f143d88b383c32782d3</a></p> <blockquote> <p><strong>We won't Accept it</strong></p> <p>The way in which Rails handles incoming Accept headers has been updated. This was primarily due to the fact that web browsers do not always seem to know what they want ... let alone are able to consistently articulate it. So, Accept headers are now only used for XHR requests or single item headers - meaning they're not requesting everything. If that fails, we fall back to using the params[:format].</p> <p>It's also worth noting that requests to an action in which you've only declared an XML template will no longer be automatically rendered for an HTML request (browser request). This had previously worked, not necessarily by design, but because most browsers send a catch-all Accept header ("<em>/</em>"). So, if you want to serve XML directly to a browser, be sure to provide the :xml format or explicitly specify the XML template (render "template.xml").</p> </blockquote> <p>I have an active API which is being used by many clients who are all sending both a <code>Content-Type</code> and an <code>Accept</code> header, both set to <code>application/xml</code>. This works fine, but my testing under Rails 2.3.4 demonstrates that this no longer works -- I get a 403 Unauthorised response. Remove the <code>Accept</code> header and just sending <code>Content-Type</code> works, but this clearly isn't an acceptable solution since it will require that all my clients re-code their applications.</p> <p>If I proceed to deploy to Rails 2.3.4 all the client applications which use the API will break. How can I modify my Rails app such that I can continue to serve existing API requests on Rails 2.3.4 without the clients having to change their code?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USOlly
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhy are your clients setting content-type: application/xml? Are they sending XML data along with their get/post requests? Isn't the accept header used to specify the formats you will accept, and content-type used to define the format you're sending?
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. UScoderjoe
    2. CODoes this error happen for all of your routes/verbs? If you pass application/xml content and accept header to verbs expecting data do you still get this error? I can't reproduce your problem. More info would be appreciated.
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. UScoderjoe
    3. COUse of the Content-type was originally added to the API but as you suggest isn't strictly necessary -- it's the Accept header which is used by Rails to determine which Mime Type to respond to. I'm not able to reproduce this locally in my dev environment. Could it actually be an Apache issue?
      singulars
      1. POHow to support backwards compatibility with the changes to the Accept header handling in Rails 2.3.4
      1. USOlly
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload