Fatal: Wrong mime-type in CSS responses

[Mos]

My site is down currently, because GAE response CSS files without mime-type:

REQUEST:

GET /static/css/master.css HTTP/1.1

...
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25

Accept: text/css,*/*;q=0.1
......

WRONG RESPONSE:

HTTP/1.1 200 OK
Etag: "sR7Bag"
Date: Thu, 05 Jan 2012 16:22:34 GMT
Expires: Thu, 05 Jan 2012 16:32:34 GMT
Cache-Control: public, max-age=600
Content-Type: null

Server: Google Frontend
Content-Length: 37206

Does anybody else have the problem?

[Barry Hunter]

Have you tried, specifcally specifying a mimetype?

http://code.google.com/appengine/docs/python/config/appconfig.html#Static_File_Pattern_Handlers

mime_type
Optional. If specified, all files served by this handler will be
served using the specified MIME type.

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.

[Mos]

Just found the issue http://code.google.com/p/googleappengine/issues/detail?id=6655

It's three days old and describes a fatal error that seems to hit more and more people.

No response from Google?

[Ikai Lan (Google)]

Mos, what browser is this?

I've seen some talk of this but it's passing and we can't seem to catch it in action. I need more data so I can hunt this down - URLs when this is failing. The reports I've seen are that this happens specifically to Chrome users.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

plus.ikailan.com | twitter.com/ikai

[Jon Stevens]

http://code.google.com/p/googleappengine/issues/detail?id=6655

[Mos]

Hi Ikai,

the problem occurs in all browsers (I tested Firefox, Chrome and IE).
All browsers get a mime-type of null.
Firefox is able to interpret the stylesheet nevertheless. IE and Chrome fail and the site is destroyed.

Since yesterday I have a version of my application that still has the problem.
I sent you the URL and the Beta-Login in a private email.

I need to redepoy at the weekend, so please check it in the next hours.

Greetings Mos

[Mos]

Hello Ikai,

did you have the chance to evaluate on the issue?
I sent you my broken test version / URL  two days ago.

I wanna redeploy in near future, but don't want to destroy "your test-case".

Please give some feedback.

Further I think we should put the issue on critical, because this bug breaks
webpages and many people are affected:

http://code.google.com/p/googleappengine/issues/detail?id=6655

Cheers
Mos

[Amy Unruh]

Mos (and others),

The issue is being actively investigated; we'll be sure to update this thread and the issue page as soon as there is more to report.

Mos, you can go ahead and re-deploy if you want, as we have other test cases as this point.

 

 -Amy

[James Broberg]

Pro-tip.... anyone not facing this issue, I'd advise against doing a new deployment. We weren't seeing this issue, now we are since we deployed today (Java, HR).

[Jon Stevens]

I love you appengine, but now that you are out of preview, I do expect a bit more for something that is as serious as this. Apps are totally unusable in this state and this is really taking too long to fix. I'm trying to be patient, but returning Content-type: null for 2+ weeks is pretty bad and it seems like that should get more attention than it has.

For a bit of history, I brought this issue up on 12/24/2011 on the google-appengine-java list (http://goo.gl/BdWXG) and it was ignored. I filed a ticket on 1/1/2011 and it was ignored for another 5 days until people finally started bringing it up here. Now the issue has 19 stars on it.

http://code.google.com/p/googleappengine/issues/detail?id=6655

At this point, I think this should be eating into the precious downtime count of the service. It might as well be completely down for all intensive purposes.

jon

[Joshua Smith]

On Jan 9, 2012, at 2:39 AM, Jon Stevens wrote:

all intensive purposes

FYI: The expression is "all intents and purposes." It comes from English common law.

:)

[Mos]

Hello GAE-Team,

no news in 24h on this critical issue?

I'm new to GAE and we will release our first application the next days.
But this issue make me loose my confidence in GAE's reliability. I get doubt if Google App Engine was the right choice?

As Jon mentioned: The issue is around on this list for more than two weeks.
The issue breaks applications --> downtimes for more and more of your GAEs users

And what I'm really wondering:
It seems to be a simple fix on the GAE-Frontends. It shouldn't be such a complex thing,
to evaluate why the response header sends a null mime-type and not the css mime-type for some
application's  *.css files? You have more then one test-case on this....
Your GAE guys are so smart and can't fix this one?

Cheers
Mos

[Jon Stevens]

Thanks. It was late, I was tired. =)

jon

[Brandon Wirtz]

You are kind of trolling.  

 

You aren’t as yet effected by the bug, but are complaining about the response to the issue. 

 

“Simple issue”  I kind of baited Brian the other day to ask why Numpy Savez couldn’t get a “simple” fix and he gave a pretty good explanation of the complexities of a maintaining simple fixes, but more to this point, When you are working in a huge company on a product which is made up of other teams components there are no simple fixes.

 

I am reminded of a bug that I worked on at Microsoft, Due to an issue in how packet headers supplemental data was escaped a certain combination of characters would cause the header to contain one character more than it was supposed to.  This prevented these packets from passing over multicast through cisco equipment, and would result in a video glitch in the IPTV playback. At the Core the fix was easy. Don’t put an extra character in the packet header.

 

In reality a fix meant testing that the method used for escaping data would work with this changed in 136 products, 227 brands of and models of router/switch, and running MTBF testing on the OS after.  Just the MTBF testing meant a fix would take a Month. But our “Simple” but worked out to be 3500 man hours and 75 days.

 

Simple changes meaning drastically in Enterprise for Enterprise Class environments.

[Andrin von Rechenberg]

Brandon +1

[Amy Unruh]

For those affected, it looks like a workaround is to add the following to your web.xml:

<mime-mapping>

 <extension>css</extension>

 <mime-type>text/css</mime-type>

</mime-mapping>

[Mos]

Amy, thanks for giving the workaround!

[Janeane Foster]

Great tip Amy

Thanks

[Iván Rodríguez]

+1

2012/1/10 Janeane Foster <janeane...@techsupportbase.net>

[Iván Rodríguez]

-1000 10 minutes later the css is off, what fucking is this?

[Amy Unruh]

Just to update this thread with info from another thread:

We think we know what's happening. This is something that is happening at app upload time. Can you try setting a new version name for your app, then passing the --no_batch option when using appcfg.sh?

appcfg.sh --no_batch update [YOUR_WAR_DIRECTORY]

2012/1/10 Iván Rodríguez <ivan....@gmail.com>

[Ikai Lan (Google)]

We have an SDK update that resolves this issue on upload (I've also posted in a separate thread about this):

http://code.google.com/p/googleappengine/downloads/detail?name=appengine-java-sdk-1.6.1.1.zip

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

plus.ikailan.com | twitter.com/ikai

[Mos]

Thanks to Ikai and the other GAE guys!