Completed 406 Not Acceptable

Rails
1

After migrating my 2.3.9 app to rails 3.0.0 I get this error:

  Completed 406 Not Acceptable in 513ms

I also noted that processing controller doesn’t output the protocol:

– Processing by Admin::PhotographersController#update as

while if it works, say:

– Processing by Admin::PhotographersController#update as HTML

Here is the full action output http://pastie.org/1187051

Can anyone help me, please ?
Don’t know where to start :frowning:

Luca

2

On Sep 28, 9:54 pm, lgs [email protected] wrote:

– Processing by Admin::PhotographersController#update as HTML

Here is the full action outputhttp://pastie.org/1187051

Can anyone help me, please ?
Don’t know where to start :frowning:

At a guess it’s because the url being posted to is /admin/photographer.
1 which may be making part of rails think that the requested format
is .1 (as opposed .html, .xml etc), so when you get to your respond_to
block rails can’t generate a response and so generates a 406 instead
(which is http for “I can’t generate the kind of response you asked
for”)

Fred

3

It’s goes through Admin::PhotographersController#edit action, opening
a form which I have to fill:

def edit
@photographer = current_photographer
end

then it goes to Admin::PhotographersController#update :

def update
@photographer = current_photographer
if params[:id]
# trying to update a specific photographer on a singular
resource is a no-no
flash[:notice] = “You can only update your own settings!”
redirect_to edit_resource_path
else
update!{ edit_resource_path }
end
end

here is the controller http://pastie.org/1189038
and here it is the view http://pastie.org/1189061 ( … or, follow a
snap )

= form_for(:photographer, @photographer, :url => resource_path, :html
=> { :multipart => true, :method => :put }) do |f|
…
…
%p
= f.label :theme
= f.select :theme, Photographer.themes
%p
= f.label :use_watermark, “Automatically watermark your client
photos?”
= f.check_box :use_watermark
…

Luca

On Sep 29, 10:06 am, Frederick C. [email protected]

4

… ok, this is the piece of log which works ( Rails 2.3.8 )

[paperclip] Saving attachments.
SQL (49.3ms) COMMIT
Redirected to http://localhost:3000/admin/photographer/edit
Completed in 223ms (DB: 0) | 302 Found [http://localhost/admin/
photographer]

after migrating to Rails 3.0.0 I get this:

[paperclip] Saving attachments.
SQL (595.4ms) COMMIT
Completed 406 Not Acceptable in 812ms

so I guess the failing code in my controller
Admin::PhotographersController#update is

  redirect_to edit_resource_path

… any suggestion ?
How can I procede troubleshooting ?

Thanks in advance
Luca

5

I agree with Fred. What does your ‘Accept’ header in your browser say
for the request that throws the 406? eg. Accept:text/css Also, check the
content-type in the response headers. You could grab this information
using the developer console in safari or chrome, or firebug in firefox.

I saw something very similar which affect Firefox, but not Safari or
Chrome.

Luke

6

I’m not sure to have the competence to fully understand your &
Frederick question,
so please, could you tell me how/where can I check that ?

Thanks in advance
Luca

7

On Sep 30, 12:30 pm, lgs [email protected] wrote:

I’m not sure to have the competence to fully understand your &
Frederick question,
so please, could you tell me how/where can I check that ?

I’d check what the url the form posts to is - does it look right? (ie
view the html produced by the edit form)

Fred

8

No it’s wrong, it is a POST to
http://localhost:3000/admin/photographer.1
and tha page doesn’t show up, it’s blank.

In case of Rails 2.3.8 I get - Processing
Admin::PhotographersController#update (for 127.0.0.1 at 2010-09-29
19:19:38) [PUT] - instead of POST and than redirect back to
http://localhost:3000/admin/photographer/edit

Here a vision of the failure, Firebug side:

POST photographer.1 http://localhost:3000/admin/photographer.1 406 Not
Acceptable localhost:3000 1 B

Response Headersview source
x-ua-compatible IE=Edge
Connection Keep-Alive
Content-Type text/html; charset=utf-8
Date Thu, 30 Sep 2010 12:09:14 GMT
Server WEBrick/1.3.1 (Ruby/1.8.7/2010-08-16)
X-Runtime 0.849066
Content-Length 1
Cache-Control no-cache
Set-Cookie _lauranovara_session=xxxxx …;
path=/; HttpOnly

Request Headersview source
Host localhost:3000
User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/
20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://localhost:3000/admin/photographer/edit
Cookie txtMainTab=Timeline; _lauranovara.com_session=xxxxxxxx
…

On Sep 30, 2:27 pm, Frederick C. [email protected]

9

On Sep 30, 1:49 pm, lgs [email protected] wrote:

No it’s wrong, it is a POST tohttp://localhost:3000/admin/photographer.1
and tha page doesn’t show up, it’s blank.

I’d start by finding out why the url generated ends in .1. Something
funny in your routes maybe?

Fred

10

… yes, first thing I did before my very first post,
anyway, can’t understand what’s wrong with it :

Rails 2.3.8 :

map.namespace :admin do |admin|
# session / login / logout
admin.resource :photographer_session
admin.login ‘/login’, :controller =>
“photographer_sessions”, :action => “new”
admin.logout ‘/logout’, :controller =>
“photographer_sessions”, :action => “destroy”
admin.resource :photographer
admin.resources :photographer_password_resets
…

Rails 3.0.0 :

namespace :admin do
# session / login / logout
resource :photographer_session
match ‘/login’ => ‘photographer_sessions#new’, :as => :login
match ‘/logout’ => ‘photographer_sessions#destroy’, :as
=> :logout
resource :photographer
resources :photographer_password_resets
…

everything seems ok with the new sintax …, well I think so, anyway
here what “rake routes” show up for admin photographer in both Rails
2.3.8 http://pastie.org/1191253 and Rails 3.0.0
http://pastie.org/1191246

On Sep 30, 2:51 pm, Frederick C. [email protected]

11

Given the following:

= form_for(:photographer, @photographer, :url => resource_path, :html
=> { :multipart => true, :method => :put }) do |f|
…

and

end
Should resource path be something else like admin_photographer_path ?
I’m just guessing, but I’d also look at removing the :photographer and
:method => :put from the form_for line. I think it’s import to sort out
why your URL is generating incorrectly before we troubleshoot the
content type issue. For example, it might be thinking that .1 is a
suffix just like .html or .css and is setting the resource type based on
that.

Also regarding checking the headers. I’ll assume you’re using or can use
chrome. Look under the View menu -> Developer -> Developer tools. Click
on the first item under resources (which should say 406) and click on
the headers tab. Here you can find the accept and content type headers.

Luke

12

Good point Luke, thank you.

I changed to admin_photographer_path as you suggested and it can pass
the redirection. Anyway something strange is still going on here:

  1. it redirect to http://localhost:3000/admin/photographer/edit.1

there’s still that .1 which smell of .:format mismatching …

  1. I’ve tons of that form_for(:name, @name, :url =>
    resource_path, :html => { :multipart => true, :method => :put }) do |
    f|

which are working just fine:

lsoave@ubuntu:~/rails/altrove/lauranovara$ find . -exec grep “:url =>
resource_path, :html => { :multipart => true, :method => :put })” {}
; -print|grep ^./
./app/views/admin/photos/edit.html.haml
./app/views/admin/photographers/edit.html.haml
./app/views/admin/galleries/edit.html.haml
./app/views/admin/bookings/edit.html.haml
./app/views/admin/quotes/edit.html.haml
./app/views/admin/products/edit.html.haml
./app/views/admin/pages/edit.html.haml
./app/views/admin/gallery_photos/edit.html.haml
./log/development.log
lsoave@ubuntu:~/rails/altrove/lauranovara$

  1. the old 2.3.8 used to work like that with same routing logic …

Even if this make me able to going on, I’d really would like to figure
out what makes me .1 tail :slight_smile:
Until now, I’ve no idea about why my URL is generating
incorrectly …

Many thanks to Luke and Frederick
for your precious suggestions
Luca G.Soave