Internet organisation and infrastructure
Best Current Practices
- RFC 1818 - IETF introduction of Best Current Practices
- IETF BCP index
- Wikipedia overview of IETF BCPs - IPv6, DNS, security, ...
- BCP038 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
- BCP046 Recommended Internet Service Provider Security Services and Procedures
- BCP188 Pervasive Monitoring Is an Attack
- BCP194 BGP Operations and Security
- BCP195 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
- BCP199 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
- BCP201 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms (Also RFC7696)
URI, URN, URL
A Uniform Resource Identifier (URI) is a string of characters that unambiguously identifies a particular resource.
The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence
of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute,
or natural language text in which it appears.
URI syntax was finalised in RFC 3986 (2005). The URI generic syntax consists of a hierarchical sequence of five components:
URI = scheme:[//authority]path[?query][#fragment]
where the authority component divides into three subcomponents:
authority = [userinfo@]host[:port]
URN and URL
A Uniform Resource Name (URN) is a URI that identifies a resource by name in a particular namespace.
A URN may be used to talk about a resource without implying its location or how to access it
For example, in the International Standard Book Number (ISBN) system, ISBN 0-486-27557-4 identifies a specific edition
of Shakespeare's play Romeo and Juliet. The URN for that edition would be urn:isbn:0-486-27557-4.
However, it gives no information as to where to find a copy of that book.
A Uniform Resource Locator (URL) is a URI that specifies the means of acting upon or obtaining the representation
of a resource, i.e. specifying both its primary access mechanism and network location.
For example, the URL http://example.org/wiki/Main_Page refers to a resource identified as /wiki/Main_Page,
whose representation, in the form of HTML and related code, is obtainable via the Hypertext Transfer Protocol (http:)
from a network host whose domain name is example.org.
A URN may be compared to a person's name, while a URL may be compared to their street address.
Relation to XML namespaces
In XML, a namespace is an abstract domain to which a collection of element and attribute names can be assigned.
The namespace name is a character string which must adhere to the generic URI syntax.
However, the name is generally not considered to be a URI, because the URI specification bases the decision not only on
lexical components, but also on their intended use.
An XML namespace name does not necessarily imply any of the semantics of URI schemes.
For example, a namespace name beginning with http: may have no connotation to the use of the HTTP.
The Content-Security-Policy HTTP response header helps reduce XSS risks on modern browsers by declaring
which dynamic resources are allowed to load. See CSP.com.
- HTTP WG
- HTTP/0.9, the first version, was a simple protocol for raw data transfer
across the Internet.
- HTTP/1.0 (RFC 1945), improved the protocol by allowing messages to be in the format of MIME-like
messages, containing metainformation about the data transferred and modifiers on the request/response semantics.
Did not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts.
- originally documented in RFC 2068, later updated replaced by RFC 2616 (RFC 2617 for Authentication), later replaced by the RFC 7230 family (RFC 7235 for Authentication).
- provides several optional challenge-response authentication mechanisms which can be used by a server to challenge a client
request and by a client to provide authentication information. The general framework for access authentication, and the specification of
"basic" and "digest" authentication, are specified in RFC 2617 (1999) "HTTP Authentication: Basic and Digest Access Authentication".
- RFC 7235 covers HTTP/1.1 Authentication
- Two header fields are used for carrying authentication credentials
- Authorization - note the weird terminology swapping authentication and authorisation
- Note that various custom mechanisms for user authentication use the Cookie header field for this purpose, as defined in RFC 6265
- HTTP/2 (2015)
- HTTP/2 IETF workgroup
- documented in RFC 7540 and RFC7541 (HPACK - Header Compression for HTTP/2 )
- is a more efficient expression of HTTP's semantics "on the wire".
- is supported by major web servers and browsers over TLS using an Application-Layer Protocol Negotiation (ALPN) extension where TLS 1.2 or newer is required.
- Most major browsers had added HTTP/2 support by the end of 2015.
- is the proposed successor to HTTP/2, which is already in use on the web, using UDP instead of TCP for the underlying transport protocol.
- like HTTP/2, it does not obsolete previous major versions of the protocol.
- Support was added to Cloudflare and Google Chrome (Canary build) in September 2019.
- Support in Firefox Nightly arrived in November 2019.
HTTP in a nutshell
The request message consists of:
- a request line (e.g., GET /images/logo.png HTTP/1.1)
- request header fields (e.g., Accept-Language: en).
- an empty line
- an optional message body
The response message consists of the following:
- GET : requests a representation of the specified resource.
Requests using GET should only retrieve data and should have no other effect
- HEAD: asks for a response identical to that of a GET request, but without the response body.
This is useful for retrieving meta-information written in response headers,
without having to transport the entire content
- POST: requests that the server accept the entity enclosed in the request as a new subordinate of the web resource
identified by the URI.
The data POSTed might be, for example, an annotation for existing resources;
a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of
submitting a web form to a data-handling process; or an item to add to a database.
- PUT: requests that the enclosed entity be stored under the supplied URI.
If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource,
then the server can create the resource with that URI
- DELETE: deletes the specified resource
- TRACE: echoes the received request so that a client can see what (if any) changes or additions have been made by
- OPTIONS: returns the HTTP methods that the server supports for the specified URL.
This can be used to check the functionality of a web server by requesting '*' instead of a specific resource
- CONNECT: converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted
communication (HTTPS) through an unencrypted HTTP proxy
- PATCH: applies partial modifications to a resource
- a status line which includes the status code and reason message
(e.g., HTTP/1.1 200 OK, which indicates that the client's request succeeded.)
- response header fields (e.g., Content-Type: text/html)
- an empty line
- an optional message body
An HTTP cookie (web cookie, browser cookie) is data that a server sends to a browser.
The browser may store it and send it back with the next request to the same server.
It's used to tell if two requests came from the same browser — keeping a user logged-in, for example.
It remembers stateful information for the stateless HTTP protocol.
When receiving an HTTP request, a server can send a Set-Cookie header with the response.
The cookie is usually stored by the browser, and then the cookie is sent with requests made to the same server inside a Cookie HTTP header.
With every new request to the server, the browser will send back all previously stored cookies to the server using the Cookie header.
They are only sent to the server.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of HTTP. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.
DNS and DNSSEC
Mobile IP (or IP mobility) is an IETF standard designed to allow mobile device users to move from one network to another while maintaining a permanent IP address.
Internet in Europe
See also Best Current Practices.
Internet2, IPv6, ... mobile IP ...
ISP's and peering
Peering between ISPs: Internet eXchanges (typically layer 2)