Follow RFC 4329; use application/javascript instead of text/javascript

hello
where do you add the line: AddType application/javascript .js ?
because I always message: "The web servers configuration will need to be adjusted. Was looking for application/javascript, actually got text/javascript. You might need to apply the drupal core patch located here https://drupal.org/node/2193333#comment-8469991."

I add the line after and replace the line "RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]" by "RewriteRule \.js\.gz$ - [T=application/javascript,E=no-gzip:1]"

I do not understand why I always error

To me this patch doesn't solve anything :S It stills shows the same error in advagg.

Thank you.

@mikeytown2, thank you. Apparently the problem was to have the "AllowOverride None" active. Deleted it and restarted apache and everything works cool.

Thanks.

It appeared back the error suddenly after a cron run.

That's all explanation I have :(

Yes it is, cuz this site is working 5 years without problems.

How would one fix this error without access to httpd conf, after applying the patch and receiving the same error?

I think a change like this needs some more reviews and testing across browsers/servers to make sure it's OK.

The patch also applies to Drupal 8, so I assume the same issue exists there...

Again, the patch doesn't do anything. Today fresh D7 installation with latest version of advagg, patch applied. Nothing, the warning stays.

I have the same problem, the warnings never disappear no matter what I do. But I think I found the reason.

I use CDN module, so CSS&JS are delivered to browser by a CDN server and not my Drupal server.
In the warning report "Adv CSS/JS Agg - gzip" I see an URL to the CDN server and not my Drupal server.
So I think the test reports errors about the CDN server and not my Drupal server.
I can change all I want on my server the result will never change.

So I think the test should only be done on the Drupal server, bypassing the rewrites of CDN module.

To be undoubted I desactivate CDN module... and warnings all disappear.

One workaround is to disable CDN for CSS&JS files.
Go to admin/config/development/cdn/details in CDN mapping
Remove *.js and *.css pattern
Clear All Cache and go back to admin/reports : All is perfect !!

But then I lose the advantages of using a CDN (specially performance and/or scalability)

@RaulMuroc
Yes but only for CSS & JS files and you can continue to use CDN for images and all others files.
CSS&JS are a little volume compare to others files.

Hi guys! i receive an error in my drupal 7 status page which looks like the problem in this scope:

"Adv CSS/JS Agg - Content-Type The wrong Content-Type is being sent by your web server.
The web servers configuration will need to be adjusted. Was looking for application/javascript, actually got application/x-javascript. You might need to apply the drupal core patch located here https://drupal.org/node/2193333#comment-8469991."

My webserver is nginx, and i added to the configuration to support application/javascript but, it has not solved my problem.

Will these solution helps drupal 7.34?

Br

Hi guys!

I solved the problem by change the application/x-javascript to application/javascript in nginx mimetype file.

thanks

re-uploading for bots.

We may have to add gzip to both MIME type. It's all common usage.

+++ b/.htaccess
@@ -171,3 +171,6 @@ DirectoryIndex index.php index.html index.htm
+# Follow RFC 4329; use application/javascript for .js files.

this line may not safe to use when the module is missing. let wrap it with IfMoudle..etc

I cloned it from https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess#L178, they're well-tested.

Strange, d.org taken my old upload ? adding spaces

Can I sign it off myself? Patch #29 is taken from well-tested HTML5 boilerplate and it almost same as #26. #23 has RTBC.

There was an errant space at the end of the file, this removes it. The patch also (mostly) cleanly applied to D7 and 8.2.x

Does this still fit in the realm of a change for 8.1.x? The patch applies to both 8.1.x and 8.2.x.

This needs a reroll after modifications to the .htaccess file from SA-CORE-2016-003 (8.1.7)

I'm working on the reroll as part of #D4DBoston sprint

This is the reroll on 8.1.x

Thank you @costellofax for your work on this issue! I have tested the patch in #38 and it applies cleanly for 8.1.x and 8.2.x. Let's see what the test bot says. @DamienMcKenna's patch from #34 applies cleanly for 7.x.

mmm the tests that are failing do not seem to be related with the changes we are making. Queue for retesting.

Removing the "Needs reroll" tag as this has been address already.

Thanks @dinarcon !!

The tests have passed. Yay! I have already tested this (#39). Marking RTBC. Thanks to everyone who worked on this issue!

+++ b/.htaccess
@@ -187,3 +187,9 @@ AddEncoding gzip svgz
+<IfModule mod_mime.c>
+  # Normalize to standard type.
+  # https://tools.ietf.org/html/rfc4329#section-7.2
+  AddType application/javascript .js
+</IfModule>

I don't think we should be doing this. Or we could have it commented out. I think most Apache servers are configured correctly so this is just busy work. Even the Apache that comes installed on every Mac is configured correctly. And if we're going to do this one - why stop here - sets a weird precedent.

The other change looks fine.

How's about something like this?

Backported to 7.x.

To me the change looks OK & works properly for 8.3.x as well with the patch in #47. However, I think the comment in #46 still applies: There's little point in adding the MIME type declaration commented-out – if we want to add it, then why not add it effectively? I do agree with @alexpott that declaring only the Javascript MIME type separately in .htaccess seems a bit weird, and if there aren't many proven cases in which the proper MIME type is missing from server configuration, it's busy work and shouldn't be done.

So IMO the patch should only change the RewriteRule.

The issue's been stale for a few months, so here's the patch containing only the RewriteRule per my/alexpott's suggestion, please review.

@mikeytown2, Are you sure you can RTBC your own patch then? 😆🤣😜

Hm this is a small thing that could have significant implications. I'd like to have the JS subsystem maintainers sign off on this one, and the framework managers. I pinged @drpal for a look and I see @droplet is following as well. Thanks!

Just out of couristy I was trying to figure out whether IIS has support for a similar configuration and they do: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/stat...
Their default behaviour is unknown though ...

What do other systems do?

• Wordpress: https://codex.wordpress.org/htaccess (Note; This documentation doesn't yet mention application/javascript)
• NodeJS: Express.static :
  

  $ curl -v http://localhost:5999/media/foo.js
  *   Trying ::1...
  * TCP_NODELAY set
  * Connected to localhost (::1) port 5999 (#0)
  > GET /media/foo.js HTTP/1.1
  > Host: localhost:5999
  > User-Agent: curl/7.54.0
  > Accept: */*
  >
  < HTTP/1.1 200 OK
  < X-Powered-By: Express
  < Accept-Ranges: bytes
  < Cache-Control: public, max-age=0
  < Last-Modified: Mon, 18 Sep 2017 09:55:19 GMT
  < ETag: W/"0-15e9469db58"
  < Content-Type: application/javascript
  < Content-Length: 0
  < Date: Mon, 18 Sep 2017 09:56:18 GMT
  < Connection: keep-alive
  <
  * Connection #0 to host localhost left intact
  

@dawehner,

IIS has no ZIP redirection in CORE and WP has no rewrite URL for ZIP things also. So they're both following the server configs. (ON-FLY-ZIPPING)

and I think NodeJS (and nginx) just replace the resource in the middleware. They won't change request/response Content-Type. [I can be wrong :)]

Not sure if it explains

and you should pass accept gzip to CURL:

curl -H "Accept-Encoding: gzip" -I http://drupal-site/sites/default/files/js/supppper_long_name.js

Here is yet another reroll of #2 and #53.

I think there's some risk of disruption here, so it would probably be a minor-only change. Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. Thanks!

Like alexpott said in #46 is this even still an issue? not touching anything the mime type is correct on my end, without this patch. Can we have a exemple of a setup where this problem happens before looking at the patch?

The patch is outdated BTW. After 3 years, it should be text/javascript again. LOL.

History Is Written by the Victors. 🤐🤐🤐

haha, that's a good one. Got a reference about this? wasn't aware we should be back on text/javascript :p

https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs...

Finally, the [HTML] specification is using text/javascript as the default media type of ECMAScript when preparing script tags; therefore, text/javascript has been moved intended usage from OBSOLETE to COMMON.