Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 74 additions & 0 deletions files/en-us/web/http/reference/headers/accept-query/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
---
title: Accept-Query header
short-title: Accept-Query
slug: Web/HTTP/Reference/Headers/Accept-Query
page-type: http-header
spec-urls: https://www.rfc-editor.org/info/rfc10008/#name-the-accept-query-header-fie

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI the /info URLs are the ones that get updated to have a rendered description in the spec table. That hasn't been added yet but will be at some point. In any case though, we get to see the URL in this case, which is at least a little interesting.

sidebar: http
---

The HTTP **`Accept-Query`** {{Glossary("response header")}} indicates that a resource supports the {{HTTPMethod("QUERY")}} method and identifies the query format [media types](/en-US/docs/Web/HTTP/Guides/MIME_types) that it accepts.

`Accept-Query` is a structured field whose value is a list of media ranges (a media type that might include wildcards), each represented as a structured field string or token and optionally including structured field parameters.
The order of media types in the list is not significant.
Its value applies to every URI on the server with the same path, regardless of the URI's query component.

<table class="properties">
<tbody>
<tr>
<th scope="row">Header type</th>
<td>{{Glossary("Response header")}}</td>
</tr>
</tbody>
</table>

## Syntax

```http
Accept-Query: <media-type>/<subtype>
Accept-Query: <media-type>/*
Accept-Query: */*

// Comma-separated list of media ranges in any order
Accept-Query: <media-type>/<subtype>, <media-type>/<subtype-2>, <media-type-2>/*
```

## Directives

- `<media-type>/<subtype>`
- : A [media type](/en-US/docs/Web/HTTP/Guides/MIME_types) with a subtype that the resource accepts as `QUERY` request content, such as `application/json`.
- `<media-type>/*`
- : A media type that accepts any subtype.
For example, `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.
- `*/*`
- : Any media type.

## Examples

### Advertising supported query formats

The following response indicates that the resource supports `QUERY` requests with `application/x-www-form-urlencoded` or `application/sql` content:

```http
HTTP/1.1 200 OK
Content-Type: application/json
Accept-Query: application/x-www-form-urlencoded, application/sql
```

## Specifications

{{Specifications}}

## Browser compatibility

Browser compatibility is not relevant for this header.
Browsers have no built-in handling of `Accept-Query`; it's up to the client sending `QUERY` requests to read the header and use it to select a supported media type for the request content.

## See also

- {{HTTPMethod("QUERY")}} request method
- {{HTTPHeader("Accept")}}
- {{HTTPHeader("Content-Type")}}
- {{HTTPHeader("Content-Location")}}
- {{HTTPHeader("Location")}}
- {{HTTPStatus("415", "415 Unsupported Media Type")}}
4 changes: 4 additions & 0 deletions files/en-us/web/http/reference/methods/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,9 @@ Each request method has its own semantics, but some characteristics are shared a
- {{HTTPMethod("GET")}}
- : The `GET` method requests a representation of the specified resource.
Requests using `GET` should only retrieve data and should not contain a request {{Glossary("HTTP Content", "content")}}.
- {{HTTPMethod("QUERY")}}
- : The `QUERY` method requests that the target resource process the request content in a safe and idempotent manner, returning the result in the response.
It is similar to `GET`, but allows request content with defined semantics.
- {{HTTPMethod("HEAD")}}
- : The `HEAD` method asks for a response identical to a `GET` request, but without a response body.
- {{HTTPMethod("POST")}}
Expand All @@ -38,6 +41,7 @@ The following table lists HTTP request methods and their categorization in terms
| Method | Safe | Idempotent | Cacheable |
| ------------------------- | ---- | ---------- | ------------- |
| {{HTTPMethod("GET")}} | Yes | Yes | Yes |
| {{HTTPMethod("QUERY")}} | Yes | Yes | Yes |
| {{HTTPMethod("HEAD")}} | Yes | Yes | Yes |
| {{HTTPMethod("OPTIONS")}} | Yes | Yes | No |
| {{HTTPMethod("TRACE")}} | Yes | Yes | No |
Expand Down
116 changes: 116 additions & 0 deletions files/en-us/web/http/reference/methods/query/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
---
title: QUERY request method
short-title: QUERY
slug: Web/HTTP/Reference/Methods/QUERY
page-type: http-method
spec-urls: https://www.rfc-editor.org/info/rfc10008/#name-query-method
sidebar: http
---

The **`QUERY`** HTTP method asks the target resource to process the request content in a safe and idempotent manner and return the result.
It is similar to {{HTTPMethod("POST")}} because the query is carried in the request content, but unlike `POST`, `QUERY` is explicitly {{Glossary("Safe/HTTP", "safe")}} and {{Glossary("Idempotent", "idempotent")}}.
This allows a `QUERY` request to be retried automatically without concern that it will cause additional changes to the target resource.

`QUERY` is useful when the query input is too large or complex for the target URI's query component.
The request's {{HTTPHeader("Content-Type")}} header is required and determines how the request content is interpreted by the target resource.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @gomestai This is a good start. There are some important omissions with respect to the spec though.

  1. Equivalent resource / Content-Location / Location (§2.2–2.4) . It is an important difference between POST/GET and this method that you can get back an URL with a temporary loction for getting the same data again and/or rerunning the query on current data.
    2.Content negotiation / 415 handling (§2.1) — servers reject unsupported Content-Type with 415, and Accept-Query is one way clients discover what's supported. The two pages currently connect only via a "See also" link, not in the body text. You might have a specific example for this in QUERY.

  2. Redirection and conditional requests probably worth a paragraph.

  3. Caching needs to cover that you can cache (like Get) but you have to use the body in the cache key. It stands to reason of course, but I wouldn't have though of it if I hadn't read the spec.

  4. Not sure if it is worth talking about range requests.

  5. This particular description is slightly messy in that it has "QUERY is useful when the query input is too large or complex for the target URI's query component.". What query input? Here you are drawing a relationship to using this for search queries using GET that hasn't been established.

    The spec abstract describes it very abstractly. I think we might be best starting with a line like this "this is what it is intended for" then commenting on the properties that make it suitable for that purpose.

If there ends up being too much in the top section we can add a Description section before the examples. We should look at all the examples, including those in the appendices and see what you can learn from them - might have some stuff worth capturing.

Does that make sense? If it is too much, let me know and perhaps I can help you extend it

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS MDN is usually a human readable and website developer-centric version of the spec, needed because often specs are written primarily for browser vendors (in this case the spec is actually quite readable).

In any case, we still don't just copy the spec - but we do need to copy the most important nuances of the features use in an accessible way. That's why I lean to starting with "this is mostly for implementing queries that might otherwise be too big to put in a GET", and then covering further details.

This is also the first time there's been a new HTTP method in ages. So there will be eyes on this and we want to make sure we give users the head start they need to use it effectively.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this makes sense. I’ll expand the QUERY page to cover the missing pieces from the spec in a more developer-focused way: equivalent resources with Content-Location/Location, Accept-Query discovery and 415 handling, caching behavior, redirects, and conditional requests.

I’ll also rework the intro so it doesn’t imply that QUERY is only for replacing long GET query strings, but presents that as one common use case.


<table class="properties">
<tbody>
<tr>
<th scope="row">Request has body</th>
<td>Yes</td>
</tr>
<tr>
<th scope="row">Successful response has body</th>
<td>Yes</td>
</tr>
<tr>
<th scope="row">{{Glossary("Safe/HTTP", "Safe")}}</th>
<td>Yes</td>
</tr>
<tr>
<th scope="row">{{Glossary("Idempotent")}}</th>
<td>Yes</td>
</tr>
<tr>
<th scope="row">{{Glossary("Cacheable")}}</th>
<td>Yes</td>
</tr>
<tr>
<th scope="row">
Allowed in <a href="/en-US/docs/Learn_web_development/Extensions/Forms">HTML forms</a>
</th>
<td>No</td>
</tr>
</tbody>
</table>

## Syntax

```http
QUERY <request-target>["?"<query>] HTTP/1.1
```

- `<request-target>`
- : Identifies the target resource that will process the query when combined with the information provided in the {{HTTPHeader("Host")}} header.
This is an absolute path (e.g., `/path/to/resource`) in requests to an origin server, and an absolute URL in requests to proxies (e.g., `https://example.com/path/to/resource`).
- `<query>` {{optional_inline}}
- : An optional URI query component preceded by a question mark (`?`).
It helps identify the resource being queried; the query operation itself is defined by the request content and its media type.

## Examples

### Querying a collection

The following request queries a contacts collection.
The request content selects three fields, limits the response to ten results, and filters contacts by email address:

```http
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&email=%2A%40example.%2A
```

A successful response includes the query result in the response content:

```http
HTTP/1.1 200 OK
Content-Type: application/json

[
{
"surname": "Smith",
"givenname": "John",
"email": "smith@example.org"
},
{
"surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com"
}
]
```

## Specifications

{{Specifications}}

## Browser compatibility

Browser compatibility is not relevant for this method.
Browsers have no specific integration support for `QUERY`: it isn't sent for user-initiated actions like HTML form submissions, and browsers don't send it automatically in response to other headers or mechanisms.

Developers can issue a `QUERY` request using [`fetch()`](/en-US/docs/Web/API/Window/fetch).
NOte that because `QUERY` isn't one of the CORS-safelisted methods, cross-origin requests trigger a [CORS](/en-US/docs/Web/HTTP/Guides/CORS) preflight {{HTTPMethod("OPTIONS")}} request, the same as for other non-simple methods.

## See also

- [HTTP request methods](/en-US/docs/Web/HTTP/Reference/Methods)
- {{HTTPHeader("Accept-Query")}}
- {{HTTPMethod("GET")}} and {{HTTPMethod("POST")}}
- {{HTTPHeader("Content-Type")}}
- {{HTTPHeader("Content-Location")}} and {{HTTPHeader("Location")}}
- {{HTTPHeader("Allow")}}