623115 - request for font file shouldn't return HTTP 206

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Frank Yan (:fryn)]

The bug description is vague, because I'm not sure what the cause is or what is even going on. Feel free to modify the description and the component, if you have a better understanding of this.

STR:
Loading http://frankyan.com requests a font file from http://frankyan.com/league-gothic.woff
This request returns normally with HTTP status code 200 OK, and the font face is applied correctly.
Loading http://www.alcowebizer.com/engine.php?url=http://frankyan.com requests the same font file.

Expected Behavior:
The request returns normally with HTTP status code 200 OK, and the font face is applied correctly. (This works fine in Chromium and Safari.)

Actual Behavior:
The request returns with HTTP status code 206 Partial Content, resulting the style falling back to another font.

Additional Notes:
Also, according to the Web Console, both pages request both league-gothic.woff and league-gothic.otf, when it seems like only the WOFF file should be requested. Is this intended behavior? (Only the WOFF file is requested in Chromium.)

Comment 1

[Frank Yan (:fryn)]

By the way, in case the @font-face rule has anything to do with it, the referenced stylesheet is located at http://frankyan.com/index.css

Comment 2

[Matthias Versen [:Matti]]

The font is correctly applied using Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre SeaMonkey/2.1b2pre

Why should the 206 cause a fall back to the default font ?
That is just the response to a range request that your server accepts ( Accept-Ranges:	bytes )
Could you attach a http log ?
- https://developer.mozilla.org/en/HTTP_Logging

What is your OS and what is your used Gecko version ?

Comment 3

[Jonathan Kew [:jfkthame]]

Note that @font-face requests in Gecko are subject to a same-origin restriction by default. If the site frankyan.com wants to allow cross-site access to its resources (and if licensing considerations permit this, of course), it should send a CORS header (Access-Control-Allow-Origin, IIRC) to permit this.

Comment 4

[Frank Yan (:fryn)]

Attachment: http log

Comment 5

[Frank Yan (:fryn)]

(In reply to comment #2)
> Could you attach a http log ?
> - https://developer.mozilla.org/en/HTTP_Logging

Attached above.

> What is your OS and what is your used Gecko version ?

OS X 10.6; 2.0b9pre.

User Agent String:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre

(In reply to comment #3)
> Note that @font-face requests in Gecko are subject to a same-origin restriction
> by default. If the site frankyan.com wants to allow cross-site access to its
> resources (and if licensing considerations permit this, of course), it should
> send a CORS header (Access-Control-Allow-Origin, IIRC) to permit this.

Sure; however, the font does load normally in the latest stable versions of Chrome and Safari, so I just want to make sure that the cause of this is the @font-face same-origin restriction and that it is intended and properly applied. Since it's loading normally in Seamonkey with a similarly recent revision of Gecko, there seems to be more to this.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The font file in question returns these headers when requested from alcowebizer.com, according to the attached log:

56127488[102518ff0]: http response [
56127488[102518ff0]:   HTTP/1.1 200 OK
56127488[102518ff0]:   Date: Fri, 07 Jan 2011 21:14:28 GMT
56127488[102518ff0]:   Server: Apache
56127488[102518ff0]:   Last-Modified: Tue, 03 Aug 2010 08:01:16 GMT
56127488[102518ff0]:   Etag: "baba020-52b8-48ce6b8b3cb00"
56127488[102518ff0]:   Accept-Ranges: bytes
56127488[102518ff0]:   Content-Length: 21176
56127488[102518ff0]:   Keep-Alive: timeout=2, max=100
56127488[102518ff0]:   Connection: Keep-Alive
56127488[102518ff0]:   Content-Type: text/plain
56127488[102518ff0]: ]

That doesn't include any headers indicating that it's allowed to be linked to cross-site, so the font is not used.  I have no idea what you're seeing in Seamonkey (which implements the exact same CORS checks).  Chrome and Safari don't apply CORS to font loads.

Comment 7

[Matthias Versen [:Matti]]

>I have no idea what you're seeing in Seamonkey
That was a misunderstanding from my side, I tested the only http://frankyan.com and not the second one, sorry