Idempotent methods (PUT, DELETE, and safe methods) allow clients to automatically retry requests after a communication failure, since repeating them has the same intended effect as a single request, even if the original succeeded.

http

Proactive (server-driven) content negotiation has serious disadvantages: the server cannot accurately determine what is best for the user, sending capabilities in every request is inefficient and a privacy risk, it complicates server implementations, and it limits cacheability of responses.

http, privacy

Safe methods (GET, HEAD, OPTIONS, TRACE) are defined as essentially read-only so automated retrieval processes (spiders) and cache prefetching can operate without fear of causing harm, and user agents can warn users before invoking unsafe methods.

http

The fundamental difference between POST and PUT is intent: POST asks the target resource to process the enclosed representation according to its own semantics, whereas PUT defines the enclosed representation as replacing the entire state of the target resource. PUT is therefore idempotent; POST is not.

http

HTTP allows the transfer of text media with plain CR or LF alone representing a line break when consistent for an entire representation, relaxing MIME's canonical CRLF-only requirement. This flexibility applies only to text within a representation; multipart types and HTTP header fields outside the payload must still use CRLF.

http

A client MUST NOT generate a 100-continue expectation in a request that does not include a message body. A client that receives a 417 (Expectation Failed) SHOULD repeat the request without the 100-continue expectation.

http

A client MUST NOT generate header fields in a TRACE request containing sensitive data (e.g., credentials or cookies) that might be disclosed by the response. A client MUST NOT send a message body in a TRACE request.

http, security

A client sending a CONNECT request MUST send the authority form of request-target (host:port only). Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe targets.

http

All general-purpose servers MUST support the GET and HEAD methods. All other methods are OPTIONAL.

http

An origin server MUST NOT send a validator header field (ETag, Last-Modified) in a successful response to PUT unless the representation data was saved without any transformation applied to the body and the validator reflects the new representation.

http

An origin server MUST treat a Content-Location field received in a request as transitory request context rather than metadata to be saved verbatim. An origin server MUST NOT use such context information to alter the request semantics.

http

An origin server MUST, upon receiving an HTTP/1.1 request with a 100-continue expectation, either send an immediate final status code or an immediate 100 (Continue) response; the server MUST NOT wait for the message body before sending the 100 (Continue) response.

http

An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request containing a Content-Range header field, since the payload is likely partial content mistakenly PUT as a full representation.

http

For PUT: if no current representation exists and PUT creates one, the origin server MUST send 201 (Created); if an existing representation is successfully modified, the server MUST send 200 (OK) or 204 (No Content).

http

If a POST successfully creates a resource, the origin server SHOULD send a 201 (Created) response containing a Location header field with the identifier for the primary resource created.

http

If one or more encodings have been applied to a representation, the sender MUST generate a Content-Encoding header field listing the content codings in the order in which they were applied.

http

The server MUST NOT send a message body in the response to a HEAD request; the response terminates at the end of the header section. The server SHOULD send the same header fields as it would for GET.

http

HTTP/1.1 defines eight standardized request methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE. Method tokens are case-sensitive and must be uppercase US-ASCII by convention.

http

The Content-Location header field references a URI that can be used as an identifier for a specific resource corresponding to the payload. In a 2xx response, if Content-Location matches the effective request URI, the recipient MAY treat the payload as a current representation of that resource.

http

The Content-Type header field indicates the media type of the associated representation. A sender that generates a payload body SHOULD generate a Content-Type field; recipients MAY assume 'application/octet-stream' if the field is absent.

http

The Expect header field conveys the 100-continue expectation, informing the server that the client is about to send a large message body and wishes to receive a 100 (Continue) interim response before sending it, improving efficiency when the body is large or an error is anticipated.

http

This document defines the 'HTTP Content Coding Registry' maintained by IANA. Initial registrations include 'compress' (x-compress), 'deflate', 'gzip' (x-gzip), and 'identity'.

http, registry

This document defines the 'Hypertext Transfer Protocol (HTTP) Header Field Registry' maintained by IANA for HTTP header field names. Considerations for new header fields include their applicability, whether they are hop-by-hop or end-to-end, and interaction with caching.

http, registry

Clients that perform 'content sniffing' (overriding a server's declared Content-Type by examining payload content) risk privilege escalation and incorrect processing, since many data formats match multiple media types that differ only in processing semantics. Implementers should provide a means to disable content sniffing.

http, security

CONNECT to arbitrary servers poses significant risk, particularly when the destination is a well-known port not intended for Web traffic (e.g., port 25 for SMTP), which could be used to relay spam or probe internal services. Proxies supporting CONNECT SHOULD restrict targets to a known-safe whitelist.

http, security

Origin servers translating URI paths to file system paths must guard against path traversal attacks (e.g., '..', symlinks, OS-specific naming tricks). GET semantics imply resource retrieval but must not automatically execute files in response to a GET request in a way that exposes the file system.

http, security

The User-Agent and Server header fields can expose product and version information useful to attackers for fingerprinting clients and servers. Senders should limit the granularity of information disclosed and operators should consider the privacy tradeoffs of detailed version tokens.

http, security, privacy

URIs, the Referer header, and request logs can expose sensitive information including personal data, session tokens, and credentials. HTTP does not define a confidentiality mechanism for URI components, so sensitive data should not appear in request URIs.

http, security, privacy