Side navigation
#8961 closed bug (invalid)
Opened April 25, 2011 02:39AM UTC
Closed May 09, 2011 07:44AM UTC
Last modified May 09, 2011 05:39PM UTC
"GET" ajax calls cannot send a message body. This is against the HTTP spec.
| Reported by: | deadwisdom@gmail.com | Owned by: | deadwisdom@gmail.com |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | ajax | Version: | 1.5.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
// Determine if request has content s.hasContent = !rnoContent.test( s.type );
While HEAD requests are expressly forbidden to have a message body in the HTTP spec, GET requests are free to.
I recognize that processing the "data" setting in an ajax request and appending it to the URL is a convenience for most users, so I suggest doing so as long as "processData" is set to true. Otherwise, it should be sent in the message body similar to a POST request.
I expect an argument along the lines of: "Clients shouldn't put data in a GET request because proxies and many other programs don't expect it." But this is out of the scope of your responsibility and should not be protecting the user in this way.
Attachments (0)
Change History (3)
Changed April 25, 2011 03:15AM UTC by comment:1
| component: | unfiled → ajax |
|---|---|
| owner: | → deadwisdom@gmail.com |
| priority: | undecided → low |
| status: | new → pending |
Changed May 09, 2011 07:44AM UTC by comment:2
| resolution: | → invalid |
|---|---|
| status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Changed May 09, 2011 05:39PM UTC by comment:3
This is all explained in the HTTP 1.1 Spec, RFC 2616, which you should have under your pillow.
Essentially it breaks down to the fact that the message body should be allowed unless specified otherwise in the request type specifications, as in HEAD. The GET request does not mention the message body at all, so by default should be able to use a message body. This is useful if you want to query the server with structured (e.g. JSON) data.
From Section 4.3:
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
From Section 9.3:
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.
The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.
See section 15.1.3 for security considerations when used for forms.
You haven't provided reference sources/materials.