chore(http): Improvements to HTTP messages page #36029
Conversation
github-actions
bot
added
Content:WebAPI
|
Preview URLs Flaws (6)Note! 1 document with no flaws that don't need to be listed. 🎉 URL:
External URLs (2)URL:
(comment last updated: 2024-10-22 15:37:52) |
bsmth
changed the title
|
This pull request has merge conflicts that must be resolved before it can be merged. |
bsmth
requested review from
sideshowbarker and
hamishwillee
and removed request for
a team
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
|
||
| ## HTTP Requests | ||
|  |
There was a problem hiding this comment.
Accept shown in response in image is a request header only.
| - : The request target is usually a {{glossary("URL")}} or a path and is characterized by the context of the request. | ||
| The format of the request target depends on the HTTP method used and the request context, but is described in more detail in the [Request targets](#request-targets) section below | ||
| - `<protocol>` | ||
| - : The _HTTP version_, which defines the structure of the remaining message, acting as an indicator of the expected version to use for the response. |
There was a problem hiding this comment.
List the main options?
| The last part of a request is the body. | ||
| Not all requests have one: requests with a {{HTTPMethod("GET")}} _[HTTP method](/en-US/docs/Web/HTTP/Methods)_ should only be used to request data and shouldn't contain a body. | ||
| 1. In _origin form_, the recipient combines an absolute path with the information in the {{HTTPHeader("Host")}} header. | ||
| A query string can be appended to the path for additional information (usually in `key=value` format). |
| OPTIONS * HTTP/1.1 | ||
| ``` | ||
|
|
||
| ### Request headers |
There was a problem hiding this comment.
Maybe, because not all of the headers in requests are usually referred to as request headers .. or are they ...
| ### Request headers | |
| ### Headers in requests |
|
|
||
|  | ||
|
|
||
| There are many different headers that can appear in requests, but they are categorized as follows: |
There was a problem hiding this comment.
As per comment above, https://github.com/mdn/content/pull/36029/files#r1796474253 it might be best to be clear about our headers in the request
| There are many different headers that can appear in requests, but they are categorized as follows: | |
| Some headers in a request message are explicitly referred to as request headers. Others can be sent in both requests and responses, or might have a more fine-grained categorization: |
There was a problem hiding this comment.
I only got this far in review @bsmth . Will try again Monday.
|
|
||
| Like request headers, there are many different headers that can appear in responses, and they are categorized as: | ||
|
|
||
| - {{glossary("Response header", "Response headers")}} give additional information about the server which doesn't fit in the status line. |
There was a problem hiding this comment.
True, but perhaps you might say a little more - i.e. it is also about the message - such as how the message should be cached.
| Response headers are the metadata sent with a response. | ||
| In HTTP/1.x, they are a **case-insensitive** string followed by a colon (`:`) and a value whose format depends upon which header is used. | ||
|
|
||
|  |
There was a problem hiding this comment.
Oh, didn't know ETag was a representation header - It isn't marked as such in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
I guess it should be if it describes the state of the data at a particular time.
| HTTP messages are the key in using HTTP; their structure is simple, and they are highly extensible. The HTTP/2 framing mechanism adds a new intermediate layer between the HTTP/1.x syntax and the underlying transport protocol, without fundamentally modifying it: building upon proven mechanisms. | ||
| This guide gives a general overview of the anatomy of HTTP messages from HTTP/1.X to HTTP/2. | ||
| If you've followed the examples and understood the concepts described, you should be able to work with HTTP and understand how applications can use the protocol to send and receive data. | ||
| The HTTP/2 framing mechanism adds a new intermediate layer between the HTTP/1.x syntax and the underlying transport protocol, without fundamentally modifying it, which builds upon proven mechanisms. |
There was a problem hiding this comment.
This line is dangling. If you want to keep it, swap the last two lines in the paragraph.
Are we going to talk about HTTP/3 ?
Co-authored-by: Hamish Willee <[email protected]>
Description
Rewriting some of the content, adding some details about working with HTTP/2 messages, some diagrams.
Motivation
Keeping the content up-to-date
Drafting for now, more details to follow.