Hi all, I'm wondering if this is a bug, or if I'm misunderstanding the
code. I'm looking at the ActionController respond_with method, and
noticed that any options passed through don't work for format.html.
For example:
class CommentsController < ApplicationController
respond_to :html, :xml
def new
@comment = Comment.new
respond_with(@comment, :status => :created)
end
end
For html requests, the response code will be the standard :ok 200
code. But for xml request, or json, or any other acceptable request
mime type, the :created status will be returned.
The comments in actioncontroller/metal/responder.rb would lead me to
believe that this should work.
# Display is just a shortcut to render a resource with the current
format.
class CommentsController < ApplicationController
respond_to :html, :xml
def new
@comment = Comment.new
respond_with(@comment, :status => :created)
end
end
It's off topic, but this is a curious response code to send for new.
You haven't created anything at all 
For html requests, the response code will be the standard :ok 200
code. But for xml request, or json, or any other acceptable request
mime type, the :created status will be returned.
This kind of thing is to be expected because sending the 'right'
response code to a browser doesn't lead to the correct behaviour from
a user's perspective. For example an API's create action sends a 201
response, however browsers want a 302 redirect. You can see this kind
of thing here:
https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/responder.rb#L142-167
So, should I add the test case and submit the patch, or should I
update the documentation to be clear that it doesn't work for html
requests? Oh also, it's not specific to just :status, it also doesn't
work for several other options.
I believe it's deliberate here, but if you can track down some errant
looking code, do raise a ticket with a patch.
class CommentsController < ApplicationController
respond_to :html, :xml
def new
@comment = Comment.new
respond_with(@comment, :status => :created)
end
end
It's off topic, but this is a curious response code to send for new.
You haven't created anything at all
Obviously, this isn't my actual code, it was just the shortest working example I could think of. Maybe :created was a bad example. Pretend I said :partial_content, or one of the other 50 status codes
For html requests, the response code will be the standard :ok 200
code. But for xml request, or json, or any other acceptable request
mime type, the :created status will be returned.
This kind of thing is to be expected because sending the 'right'
response code to a browser doesn't lead to the correct behaviour from
a user's perspective. For example an API's create action sends a 201
response, however browsers want a 302 redirect. You can see this kind
of thing here:
https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/responder.rb#L142-167
Not necessarily. My specific use-case is with sending an AJAX request (via the jquery-ujs) for an HTML snippet. The jQuery callbacks look at the response code, and so it is useful to have control over them without needing to resort to respond_to or format.html{ ... }.
Also, it's not just :status, I can't override :layout either. This doesn't work for html requests either:
respond_with(@comment, :layout => :false)
So, should I add the test case and submit the patch, or should I
update the documentation to be clear that it doesn't work for html
requests? Oh also, it's not specific to just :status, it also doesn't
work for several other options.
I believe it's deliberate here, but if you can track down some errant
looking code, do raise a ticket with a patch.
If it's a bug, I have no problem writing the tests, fixing it, and submitting the patch. I just wanted to make sure there's not some obvious reason I'm missing that this behavior would be intended.
Not necessarily. My specific use-case is with sending an AJAX request (via
the jquery-ujs) for an HTML snippet. The jQuery callbacks look at the
response code, and so it is useful to have control over them without needing
to resort to respond_to or format.html{ ... }.
I think your best bet will be to subclass the responders and remove
this 'browser vs api' distinction. We won't be able to remove those
without breaking lots of people's apps. Currently it's a feature that
you can safely say have code like this and have it redirect browsers
back to the index action.
respond_with(@comment, :status=>:created)
I see, that makes sense. At the very least, I'll submit a patch that makes the :layout option work. After all, the html format is the only one that parameter makes sense for; if the developer puts :layout => false (or some other template) in their respond_with options, it's obvious they mean the html format.
respond_with(@comment, :layout => false)
Thanks Koz!