ietf - Dave's Blog


Search

http://tools.ietf.org/html/draft-wkumari-not-a-draft-00

10 days ago
tp://tools.ietf.org/html/draft-wkumari-not-a-draft-00
PermalinkCommentshumor technical ietf atlanteans

Considerate MessagePort Usage

2013 Aug 7, 7:14
Sharing by leezie5. Two squirrels sharing food hanging from a bird feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.When writing a JavaScript library that uses postMessage and the message event, I must be considerate of other JS code that will be running along side my library. I shouldn't assume I'm the only sender and receiver on a caller provided MessagePort object. This means obviously I should use addEventListener("message" rather than the onmessage property (see related What if two programs did this?). But considering the actual messages traveling over the message channel I have the issue of accidentally processing another libraries messages and having another library accidentally process my own message. I have a few options for playing nice in this regard:
Require a caller provided unique MessagePort
This solves the problem but puts a lot of work on the caller who may not notice nor follow this requirement.
Uniquely mark my messages
To ensure I'm acting upon my own messages and not messages that happen to have similar properties as my own, I place a 'type' property on my postMessage data with a value of a URN unique to me and my JS library. Usually because its easy I use a UUID URN. There's no way someone will coincidentally produce this same URN. With this I can be sure I'm not processing someone else's messages. Of course there's no way to modify my postMessage data to prevent another library from accidentally processing my messages as their own. I can only hope they take similar steps as this and see that my messages are not their own.
Use caller provided MessagePort only to upgrade to new unique MessagePort
I can also make my own unique MessagePort for which only my library will have the end points. This does still require the caller to provide an initial message channel over which I can communicate my new unique MessagePort which means I still have the problems above. However it clearly reduces the surface area of the problem since I only need once message to communicate the new MessagePort.
The best solution is likely all of the above.
Photo is Sharing by leezie5. Two squirrels sharing food hanging from a bird feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.
PermalinkCommentsDOM html javascript messagechannel postMessage programming technical

draft-ietf-websec-framework-reqs-00 - Web Security Framework: Problem Statement and Requirements

2013 Feb 20, 2:48

Web Security Framework: Problem Statement and Requirements

PermalinkCommentstechnical rfc security web html

Indicating Details of Problems to Machines in HTTP

2012 Jul 3, 2:28

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.

PermalinkCommentstechnical http ietf standard

JSON Hypermedia API Language

2012 Jul 1, 1:52

The JSON Hypermedia API Language (HAL) is a standard which establishes conventions for expressing hypermedia controls, such as links, with JSON.

PermalinkCommentsjson uri url link technical standard ietf

The "acct" URI Scheme

2012 Jun 30, 3:09

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

PermalinkCommentstechnical uri uri-scheme acct ietf

HTTP Compression Documentation Reference

2012 Jun 13, 3:08
There's a lot of name reuse in HTTP compression so I've made the following to help myself keep it straight.
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.

PermalinkCommentscompress compression deflate gzip http http-header technical zlib

A New HTTP Status Code for Legally-restricted Resources

2012 Jun 11, 2:00

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.

PermalinkCommentshttp internet web 451 law legal rfc ietf censorship technical

"Additional Media Type Structured Syntax Suffixes" - Tony Hansen

2012 Apr 26, 3:15

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.

PermalinkCommentstechnical json mime ietf rfc standard

Recommendations for the Remediation of Bots in ISP Networks

2012 Mar 19, 3:11

recommendations on how Internet Service
   Providers can use various remediation techniques to manage the
   effects of malicious bot infestations on computers used by their
   subscribers.

Detection and notification recommendations.

PermalinkCommentstechnical isp ietf networking

Alternate IPv4 Forms - URI Host Syntax Notes

2012 Mar 14, 4:30

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:

192.168.1.1
Standard dotted decimal form
0300.0250.01.01
Octal
0xC0.0XA8.0x1.0X1
Hex
192.168.257
Fewer parts
0300.0XA8.257
All of the above

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.

PermalinkCommentsurl inet_aton uri technical host programming ipv4

WHATWG Weekly: http+aes URL scheme, control Referer, …

2012 Mar 7, 8:08

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.

PermalinkCommentstechnical html5 html uri uri-scheme http http+aes

URI Percent-Encoding Ignorance Level 1 - Purpose

2012 Feb 15, 4:00

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:

  1. http://example.com/the%20path/
  2. http://example.com/the path/
In the above the first is a valid URI while the second is not valid since a space appears directly in the URI. Depending on the context and the code through which the wannabe URI is run one may get unexpected failure.

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:

  1. http://example.com/foo%3Fbar
  2. http://example.com/foo?bar
In the second, the question mark appears plainly and so delimits the path "/foo" from the query "bar". And in the first, the querstion mark is percent-encoded and so the path is "/foo%3Fbar".
PermalinkCommentsencoding uri technical ietf percent-encoding

URI Percent Encoding Ignorance Level 0 - Existence

2012 Feb 10, 4:00

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.

PermalinkCommentsencoding uri technical ietf percent-encoding ipv6

"Forwarded HTTP Extension" - Andreas Petersson, Martin Nilsson

2012 Jan 27, 9:41PermalinkCommentstechnical http http-header proxy ietf standard

"Unified User-Agent String (UUAS)" - Mateusz Karcz

2012 Jan 27, 7:29

IETF draft on the contents of the User Agent HTTP header.

PermalinkCommentstechnical ietf http user-agent http-header

Features of image type input tags in HTML

2011 Nov 21, 11:00

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:

<form action="http://example.com/">
<input type="image" name="foo" src="http://deletethis.net/dave/images/davebefore.jpg">
</form>
If the user clicks on the image, the browser will submit the form with a URI like the following:http://example.com/?foo.x=145&foo.y=124.

This seemed like an incredibly specific feature to be built directly into the language when this could instead be done with javascript. I looked a bit further and saw that its been in HTML since at least HTML2, which of course makes much more sense. Javascript barely existed at that point and sending off the user's click location in a form may have been the only way to do something interesting with that action.

PermalinkCommentsuri technical form history html

"Forwarded HTTP Extension" - Andreas Petersson, Martin Nilsson

2011 Nov 17, 3:30

Describes forward HTTP headers to explicitly list proxying information that might otherwise be lost.

PermalinkCommentstechnical ietf http http-header proxy

"JSON Patch" - Paul Bryan

2011 Nov 17, 1:06

Mime-type for describing the difference between two JSON resources (in JSON using JSON paths)

PermalinkCommentstechnical mime mime-type json ietf

"JSON Reference" - Paul Bryan, Kris Zyp

2011 Nov 14, 8:24PermalinkCommentstechnical json ietf
Older Entries Creative Commons License Some rights reserved.