New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

XMLHttpRequest of type DELETE

Reported by mich...@mahemoff.com, Dec 12 2011 Back to list

Issue description

Chrome Version       : 17.0.963.2
OS Version: OS X 10.7.0
URLs (if applicable) :
Other browsers tested:
  Firefox 8.0.2: OK
  Opera 11.52: OK

What steps will reproduce the problem?
1. Make a XMLHttpRequest call with DELETE method to a server which returns a 302 redirect (to a different location)

What is the expected result?

An automatic GET request should be triggered once the initial XHR call returns to the browser. ie server should register a DELETE, with 302 response, immediately followed by a GET to the location specified in the first response.

What happens instead?

An automatic DELETE request is triggered. ie DELETE instead of GET. Server registers a DELETE with 302 response, immediately followed by a second DELETE to the location specified in the first response.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_0) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.2 Safari/535.11



 

Comment 1 by mmenke@chromium.org, Dec 12 2011

Labels: -OS-Mac -Area-Undefined OS-All Area-Internals Internals-Network-HTTP
Status: WontFix
This is correct behavior, according to all the HTTP RFCs:  1945, 2068, 2616, and the latest httpbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17).  HTTP 2616 mentions that many browsers rewrite the request in violation of spec.  The latest httpbis spec allows POSTs to be converted to GETs on 302s, which we do, but still requires not rewriting other request types.

If you want to receive a GET instead, you should be using a 303 redirect, as per spec.
Thanks for looking into it. I've blogged some thoughts and workarounds for anyone having similar issues http://softwareas.com/the-weirdness-of-ajax-redirects-some-workarounds

Comment 3 by mmenke@chromium.org, Dec 12 2011

No problem.  If this turns out to be a major issue, we could theoretically roll it back, but I don't think it's too likely.

The original bug, if you're interested:  http://crbug.com/56373 .  I believe it made it into Chrome 16, but don't quote me on that.

Comment 4 by Deleted ...@, May 7 2012

HTTP RFC 2616 (and the draft you linked) seems to say the opposite:

>   If the 302 status code is received in response to a request method
>   that is known to be "safe", as defined in Section 6.1.1, then the
>   request MAY be automatically redirected by the user agent without
>   confirmation.  Otherwise, the user agent MUST NOT automatically
>   redirect the request unless it can be confirmed by the user, since
>   this might change the conditions under which the request was issued.

The definition of 'safe' reads:

>   In particular, the convention has been established that the GET,
>   HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
>   significance of taking an action other than retrieval.  These request
>   methods ought to be considered "safe".  This allows user agents to
>   represent other methods, such as POST, PUT and DELETE, in a special
>   way, so that the user is made aware of the fact that a possibly
>   unsafe action is being requested.

DELETE is an 'unsafe' request method, and therefore 'must not' automatically redirect the request unless it can be confirmed by the user. Am I misreading something?
Maintaining the method (Not converting to GET, as you were expecting) is the correct behavior, as per spec, which is what the question was about, not the fact there was no popup.  If you want a request to be converted to a GET, you should use a 303 redirect.

The fact that it's automatic rather than using a popup for confirmation is mostly a result of IE not doing so, and maintaining cross-browser consistency.  Also, providing end-users with random modal dialogs they are completely unequipped to answer makes for a rather poor user experience.
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network-HTTP Cr-Internals-Network-HTTP Cr-Internals

Sign in to add a comment