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.)
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
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 ?
Component: General → Layout: Text
QA Contact: general → layout.fonts-and-text
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.
(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.
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
>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
You need to log in before you can comment on or make changes to this bug.