Sharovatov’s Weblog

Opera to reinvent the web?

Posted in browsers by sharovatov on 15 June 2009

Opera promises to reinvent the web tomorrow. I mean, really, reinvent the web? Invent TCP/IP, HTTP, DNS, HTML/CSS/JS, CGI, all other stuff that web consists of? I doubt.

Different sources speculate that it’s going to be something cloud-related. Maybe it will be a p2p-based traffic sharing with some clever algorithm to determine where to download the data from? But then I wouldn’t like anybody to be able to sniff my data. Maybe they will install a CDN to make useless Opera Turbo giving at least some performance benefit to users. Don’t know, we’ll see very soon.

But because of the last unfair actions that were taken by Opera against IE, I (from moral prospective) really hope that all the expenses they took for Opera 10 PR won’t significantly increase their market share. Competition should be fair, Firefox was able to get the same market share as IE in Germany without making users life harder. I really hope that lobbying expenses were higher than the income.

Tagged with: , ,

Windows 7 will be shipped without IE8 in Europe?

Posted in browsers, IE8, windows 7 by sharovatov on 11 June 2009

As CNET states, Windows 7 will be shipped to Europe without IE8 because European antitrust regulators told them so. This clearly shows how rotten EU antitrust committee is and how easy it is for a well settled lobby to force the whole EU to accept absolutely stupid and nonsense act.

Who will gain any profit from this?

Users? No, they will have to find a way to get any browser on their new computer. And what if it’s their first computer? How are they supposed to download anything from the internet? Yes it’s a five minutes job for an IT specialist, but go teach your grandmother how to use ftp.exe to download anything ;)

Hardware vendors? No, they were always able to install any browser on the computers they sell and make it the default one.

Other browser vendors? To a degree. Anyway Microsoft will provide hardware resellers with an IE8 pack – so they can install IE8 on all the computers they build.

Is there any sense at all in this decision? I can’t see it.

I just don’t get it, really. If I’m buying a car, I won’t argue that the tyres on this new car are from Pirelli (or any other vendor). I will just change them if I don’t really like Pirelli, or choose another car which doesn’t have Pirelly. I’m not prohibited to change them. I’m just given the default one.

And now compare this situation with Apple who clearly prohibits installing Opera on its iPhone. Because it would compete (and, obviously, win the competition) with their Safari browser. Why doesn’t EU antitrust committee look at this? Why don’t Opera take any action here?


Share :

Tagged with: , , , ,

HTTP History Lists and Back Button

Posted in browsers, http by sharovatov on 3 June 2008

While writing the post about forms values persistence, I noticed that browsers handle back button in different HTTP situations differently.

HTTP 1.1 spec says the following:

13.13 History Lists

 User agents often have history mechanisms, such as "Back" buttons and
 history lists, which can be used to redisplay an entity retrieved
 earlier in a session.

 History mechanisms and caches are different. In particular history
 mechanisms SHOULD NOT try to show a semantically transparent view of
 the current state of a resource. Rather, a history mechanism is meant
 to show exactly what the user saw at the time when the resource was
 retrieved.

 By default, an expiration time does not apply to history mechanisms.
 If the entity is still in storage, a history mechanism SHOULD display
 it even if the entity has expired, unless the user has specifically
 configured the agent to refresh expired history documents.

 This is not to be construed to prohibit the history mechanism from
 telling the user that a view might be stale.

So it clearly recommends UA authors to separate history list and cache behaviour. So if user navigates through the history list (using Back or Forward buttons), HTTP spec recommends to show the exact response that the user saw before, regardless if it's stale or expired.

I've tested 4 major browsers — IE, FF, Opera and Safari, and here is the summary table:

Expires in the future +
Conditional GET validators
no request no request no request no request
Expires in the future no request no request no request no request
Conditional GET validators no request no request no request no request
no HTTP caching headers no request no request no request full request
Expires in the past no request no request no request full request
Cache-Control: no-store full request full request no request full request
Cache-Control: no-store +
Expires in the past
full request full request no request full request
Page served with IE8 FF Opera Safari

So we can see that only Opera follows HTTP 1.1 recommendation.

Obviously IE and FF don't produce a request when HTTP caching is not explicitly prohibited which is against the HTTP spec recommendation, but this was done intentionally asauthors usually prohibit caching for a reason and don't want users to view those pages without revalidating.

And Safari just does the full request whenever the page is not cached explicitly.

Tagged with: , , , ,

data URI browser issues

Posted in browsers, css, javascript by sharovatov on 13 May 2008

Length limit

Theory

data URI specification says the following:

some applications that use URLs may impose a length limit; for
example, URLs embedded within <A> anchors in HTML have a length limit
determined by the SGML declaration for HTML [RFC1866]. The LITLEN
(1024) limits the number of characters which can appear in a single
attribute value literal, the ATTSPLEN (2100) limits the sum of all
lengths of all attribute value specifications which appear in a tag,
and the TAGLEN (2100) limits the overall length of a tag.

Though at the time of writing data URI specification HTML3.2 was current HTML recommendation, author intentionally used LITLEN, ATTSPLEN and TAGLEN values from the older HTML2.0 SGML declaration to show that some user-agents may impose a length limit for URI.

HTTP1.1 doesn’t put a limit on the length of URI, but it warns us:

Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.

which basically means that if all clients in the network support URIes more than 255 bytes long, we’re ok.

HTML3.2 SGML declaration states the maximum length of an attribute to be 65535. Even more, HTML4.01 SGML declaration uses value 65535 as a maximum allowed in SGML but says that fixed limits should be avoided. XML1.0 SGML declaration uses 99999999 value just to show that there’s no limit specified.

Practice

Different browsers have different maximum length of dataURI’ed values supported.

As per the kb208427 article, IE supports URI length of up to 2048 bytes. According to the Microsoft IE8 data URI support whitepaper, IE8 supports up to 32Kbytes of data URI and silently discards dataURI value if its size exceeds 32Kbytes (which can be checked in the testcase1 and testcase2). As I’ve already mentioned in the previous post, other browsers provide bigger-sized URI support, but I doubt that IE8 will have minor market share so we will still have to stick to 32Kbytes. And I will repeat: data URI spec author that the only reasonable and semantic use of data URI is embedding small resources, so realistically speaking 32Kbytes limit shouldn’t be a problem.

Serving CSS dataURI’ed

In theory, CSS has to be served with its MIME type (text/css).

In practice, only Firefox and only in standards compliancy mode cares about MIME type that CSS’s been served with. Please see the testcases with CSS served with wrong MIME type in different render modes: in standards compliancy mode and in quirks mode. Opera, Safari and Internet Explorer 8 all apply CSS served with any MIME type in all modes. The behaviour is the same for both CSS files served using dataURI and by referencing normal external files.

Serving Javascript and HTML dataURI’ed

Safari, Opera and Firefox support embedding javascript using data URI scheme. According to the whitepaper, IE8b1 doesn’t support this. Here’s the quote:


Scripts in data URIs are unsupported because they allow potentially harmful script to bypass server- and

proxy-script filters for applications such as HTML email. (Web-based email clients generally do not allow

emails to execute script; data URIs could be used to easily bypass these filters).

I do agree that this is a valid point, it is a potential security issue, dataURIed javascript is even published as an XSS vector. Please see the testcase.

Opera and Safari run dataURI’ed HTML page in a separate isolated context, IE8b1 doesn’t support dataURI’ed html at all, so the only affected browser here is Firefox. There’s an interesting bugzilla entry describing the XSS (marked as duplicate to the security proposal) which says:


The attack works by exploiting an ambiguity in RFC 2397 with regard to the Javascript same-origin security policy — what is the origin of a URI? Is it the containing page? If so, preventing this attack is the responsibility of site maintainers. If not, FF should launch the child of a data: URI without

same-origin privileges.

Firefox authors reply that this is site maintainers’ problem to filter dataURI and compare this to filtering javascript: (which is quite fair) but why did they want to create a new hole in all the sites for some vague benefits of executing dataURI’ed scripts in the same context?

To me it seems a bit weird especially looking at the fact that other browsers do care about execution context. The bugzilla entry is still opened, but I doubt that this is going to be fixed. So, “site maintainers”, be aware!

Nested dataURI’es

Neither dataURI spec nor any other mentions if dataURI’es can not be nested. So here’s the testcase where dataURI’ed CSS has dataURI’ed image embedded. IE8b1, Firefox3 and Safari applied the stylesheet and showed the image, Opera9.50 (build 9613) applies the stylesheet but doesn’t show the embedded image! So it seems that Opera9 doesn’t expect to get anything embedded inside of an already embedded resource! :D

But funny thing, as IE8b1 supports expressions and also supports nested data URI’es, it has the same potential security flaw as Firefox does (as described in the section above). See the testcase — embedded CSS has the following code: body { background: expression(a()); } which calls function a() defined in the javascript of the main page, and this function is called every time the expression is reevaluated. Though IE8b1 has limited expressions support (which is going to be explained in a separate post) you can’t use any code as the expression value, but you can only call already defined functions or use direct string values. So in order to exploit this feature we need to have a ready javascript function already located on the page and then we can just call it from the expression embedded in the stylesheet. That’s not very trivial obviously, but if you have a website that allows people to specify their own stylesheets and you want to be on the safe side, you have to either make sure you don’t have a javascript function that can cause any potential harm or filter expressions from people’s stylesheets.

Line feeds

Firefox, Opera, Safari and IE8b1 support both data URI values supplied as one line (as an URI) and splitted by 76 bytes (as specified in MIME and MHTML RFCs). See the testcase.

But base64 RFC doesn’t put a requirement to split base64 strings:

MIME [3] is often used as a reference for base 64 encoding.  However,
MIME does not define "base 64" per se, but rather a "base 64
Content-Transfer-Encoding" for use within MIME.  As such, MIME
enforces a limit on line length of base 64 encoded data to 76
characters.  MIME inherits the encoding from PEM [2] stating it is
"virtually identical", however PEM uses a line length of 64
characters.  The MIME and PEM limits are both due to limits within
SMTP.

Implementations MUST NOT not add line feeds to base encoded data
unless the specification referring to this document explicitly
directs base encoders to add line feeds after a specific number of
characters.

DataURIed images with images turned off

When you turn off images in your browser, only Firefox still shows dataURIed images. IE8b1, Safari and Opera don’t show the image as it’s supposed to be when you turn the images off. To test this turn off images in your browser and run the testcase.

UPDATE: Firefox developers told me this is by design as unchecking “Load images automatically” option in the browser settings disables only network request to get the image. So if the image is accessible without doing a network request — either from cache or embedded as dataURI, it will be displayed in any case.

Dynamically created dataURIes

As dataURI can contain binary data (e.g. to show images), there are thoughts on using this. Ajaxian has a crazy article on creating pure JS video player that doesn’t use flash but changes dataURI’ed images instead. This technique may get some practical evolution and usage, but now it’s rather impractical.

Links and references

P.S. And here’s a great tool from Nicholas C. Zakas – CSSEmbed – it reads the CSS file you want, finds all the images references, converts images to dataURIes and saves resulting CSS file. So if you have small presentational images referenced in your CSS file, feed CSSEmbed with your CSS file and you’ll get them all converted in one go! Nice and simple! This tool can be also easily integrated into your publishing process if required. Thanks Nicholas!

Share :

Tagged with: , , , ,
Follow

Get every new post delivered to your Inbox.