Web Security Framework: Problem Statement and Requirements
This specification defines a “Problem Detail” as an extensible way to carry machine-readable details of errors in a response, to avoid the need to invent new response formats.
The JSON Hypermedia API Language (HAL) is a standard which establishes conventions for expressing hypermedia controls, such as links, with JSON.
During formalization of the WebFinger protocol [I-D.jones-appsawg-webfinger], much discussion occurred regarding the appropriate URI scheme to include when specifying a user’s account as a web link [RFC5988].
acctURI = “acct:” userpart “@” domainpart
|HTTP Content Coding Token||gzip||deflate||compress|
|An encoding format produced by the file compression program "gzip" (GNU zip)||The "zlib" format as described in RFC 1950.||The encoding format produced by the common UNIX file compression program "compress".|
|Data Format||GZIP file format||ZLIB Compressed Data Format||The compress program's file format|
|Compression Method||Deflate compression method||LZW|
|Deflate consists of LZ77 and Huffman coding|
Compress doesn't seem to be supported by popular current browsers, possibly due to its past with patents.
Deflate isn't done correctly all the time. Some servers would send the deflate data format instead of the zlib data format and at least some versions of Internet Explorer expect deflate data format instead of zlib data format.
451 Unavailable for Legal Reasons: The 451 status code is optional; clients cannot rely upon its use. It is imaginable that certain legal authorities may wish to avoid transparency, and not only forbid access to certain resources, but also disclosure that the restriction exists.
That was fast.
This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the “+json”, “+ber”, “+der”, “+fastinfoset”, “+wbxml” and “+zip” Structured Syntax Suffixes, and updates the “+xml” Structured Syntax Suffix registration.
recommendations on how Internet Service
Providers can use various remediation techniques to manage the
effects of malicious bot infestations on computers used by their
Detection and notification recommendations.
By the URI RFC there is only one way to represent a particular IPv4 address in the host of a URI. This is the standard dotted decimal notation of four bytes in decimal with no leading zeroes delimited by periods. And no leading zeros are allowed which means there's only one textual representation of a particular IPv4 address.
However as discussed in the URI RFC, there are other forms of IPv4 addresses that although not officially allowed are generally accepted. Many implementations used inet_aton to parse the address from the URI which accepts more than just dotted decimal. Instead of dotted decimal, each dot delimited part can be in decimal, octal (if preceded by a '0') or hex (if preceded by '0x' or '0X'). And that's each section individually - they don't have to match. And there need not be 4 parts: there can be between 1 and 4 (inclusive). In case of less than 4, the last part in the string represents all of the left over bytes, not just one.
For example the following are all equivalent:
The bread and butter of URI related security issues is when one part of the system disagrees with another about the interpretation of the URI. So this non-standard, non-normal form syntax has been been a great source of security issues in the past. Its mostly well known now (CreateUri normalizes these non-normal forms to dotted decimal), but occasionally a good tool for bypassing naive URI blocking systems.
Seems generally bad to embed sensitive info in the URI (the http+aes URI scheme’s decryption key) similar to the now deprecated password field.
Use case is covered here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0811.html. Also discussion including someone mentioning the issue above.
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping).
Worse than the lame blog comments hating on percent-encoding is the shipping code which can do actual damage. In one very large project I won't name, I've fixed code that decodes all percent-encoded octets in a URI in order to get rid of pesky percents before calling ShellExecute. An unnamed developer with similar intent but clearly much craftier did the same thing in a loop until the string's length stopped changing. As it turns out percent-encoding serves a purpose and can't just be removed arbitrarily.
Percent-encoding exists so that one can represent data in a URI that would otherwise not be allowed or would be interpretted as a delimiter instead of data. For example, the space character (U+0020) is not allowed in a URI and so must be percent-encoded in order to appear in a URI:
For an additional example, the question mark delimits the path from the query. If one wanted the question mark to appear as part of the path rather than delimit the path from the query, it must be percent-encoded:
/foo" from the query "
bar". And in the first, the querstion mark is percent-encoded and so the path is "
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping). The basest ignorance is with respect to the mere existence of percent-encoding. Percents in URIs are special: they always represent the start of a percent-encoded octet. That is to say, a percent is always followed by two hex digits that represents a value between 0 and 255 and doesn't show up in a URI otherwise.
The IPv6 textual syntax for scoped addresses uses the '%' to delimit the zone ID from the rest of the address. When it came time to define how to represent scoped IPv6 addresses in URIs there were two camps: Folks who wanted to use the IPv6 format as is in the URI, and those who wanted to encode or replace the '%' with a different character. The resulting thread was more lively than what shows up on the IETF URI discussion mailing list. Ultimately we went with a percent-encoded '%' which means the percent maintains its special status and singular purpose.
IETF draft on the contents of the User Agent HTTP header.
A bug came up the other day involving markup containing
<input type="image" src="http://example.com/.... I knew that "image" was a valid input type but it wasn't until that moment
that I realized I didn't know what it did. Looking it up I found that it displays the specified image and when the user clicks on the image, the form is submitted with an additional two name
value pairs: the x and y positions of the point at which the user clicked the image.
Take for example the following HTML:
If the user clicks on the image, the browser will submit the form with a URI like the following:
<input type="image" name="foo" src="http://deletethis.net/dave/images/davebefore.jpg">
Describes forward HTTP headers to explicitly list proxying information that might otherwise be lost.
Mime-type for describing the difference between two JSON resources (in JSON using JSON paths)
Includes ‘511 Network Authentication Required’ for airport/hotel/coffee shop scenarios! Am I too excited about this?