allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brondsema" <>
Subject [allura:tickets] #7971 Incorrect Content-Type on first CSS requests, causing CSS not to be used
Date Wed, 23 Sep 2015 15:57:05 GMT
**tl;dr** I've fixed one issue in EasyWidgets and upgraded Allura's version of it.  Not sure
if it fixes root cause

I'm not sure why the content type is missing (and not detected) in the first place, but I
have found a bug in EasyWidgets where the headers from one request were essentially being
saved and re-used again for subsequent requests.  This is fixed in

You can see for example:

    # substitute 1276635823 if you have a different build_key in your .ini file
    curl -I 'http://localhost/nf/1276635823/_ew_/allura/fonts/fontawesome-webfont.woff'  
# Content-Type: application/octet-stream   Correct, since woff isn't known
    curl -I 'http://localhost/nf/1276635823/_ew_/allura/css/forge/hilite.css'   # Content-Type:
text/css    Correct
    curl -I 'http://localhost/nf/1276635823/_ew_/allura/fonts/fontawesome-webfont.woff'  
# Content-Type: text/css    Incorrect, using header from last response

Upgrading EasyWidgets should fix that particular bug.  Not entirely sure if it fixes the original
issue, since I dont' know why the type isn't picked up the first time, sometimes.  So I've
gone ahead and done that, but leaving this ticket open to find out if any issues remain.

If/when we finally fix this, we should also remove the `<h2 class="hidden">` section
in `Allura/allura/templates/jinja_master/master.html`.  It shows up in search engines sometimes


** [tickets:#7971] Incorrect Content-Type on first CSS requests, causing CSS not to be used**

**Status:** in-progress
**Milestone:** unreleased
**Labels:** ux getting-started sf-2 sf-current 
**Created:** Tue Aug 18, 2015 03:52 PM UTC by Dave Brondsema
**Last Updated:** Mon Sep 21, 2015 03:58 PM UTC
**Owner:** Dave Brondsema

I can't pull up an example right now unfortunately since it's only occasional.  I think the
URLs are the ones with `_ew_` in the path.

And then if the response gets cached, then subsequent page loads still don't work either.

[#7028] was for the same issue, so see that for additional details.  That ticket just resulted
in a workaround, but its not great (especially if it gets cached).  This ticket is for a real


Sent from because is subscribed to

To unsubscribe from further messages, a project admin can change settings at
 Or, if this is a mailing list, you can unsubscribe from the mailing list.
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message