Webform asset javascript (webform/javascript/webform_id/custom.js) is showing not found

Are you saying that the changes in commit 2fc9b78 are what broke this? If you taken 6.3.x and revert that commit, does it fix it?

I have tried with version 6.2.2 and it's working fine. For webform version 6.3.x still an issue.

If you use 6.3.x and revert commit 2fc9b78, does it work?

I can't reproduce this bug in the latest 6.2 release. The JavaScript works for me. So we need improved steps to reproduce.

Oh, I've misread the details here. Let me try again.

I also can't reproduce the bug on 6.3.x.

Having the same issue, strangely enough this only happens on server, dev or production but not locally

I also experienced this issue after upgrading to 6.2.7. The javascript fails to load and I receive a browser error message 'The resource from '.../custom.js' was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff)." I downgraded to 6.2.4 and received the same error. I then downgraded to 6.2.2 and the javascript loads correctly on that version.

You can use git bisect to figure out which commit was the change that caused this problem.

Thank you for the tip liam. Yes it shows commit 2fc9b78 as the first bad commit for me.

If you take the latest 6.3.x and revert commit 2fc9b78, does that fix it?

Yes, reverting that commit from 6.3.x does get the custom javascript working for me again.

I was having the same problem with css and javascript, I found out that the module fast_404 → was causing the bug, because of the new routing with extension (.ccs, .js).
In my case, uninstalling fast_404 fixed the issue.

I create a patch to revert the code change of css and js asset.

\Drupal\webform\Controller\WebformEntityController::javascript and \Drupal\webform\Controller\WebformEntityController::css are setting the correct content type in the header.

I think we have to keep *.css and *.js extension so that Ajax works as expected.

This is happening to us too. We use the wodby/nginx image as our server both locally and on the public internet, and by default it identifies a range of file extensions as static files, including .css and .js. It will then attempt to load requests for paths matching those extensions as static files only, with PHP execution disabled. Where custom.css and custom.js are generated by PHP, that obviously won't cut it.

As far as I can tell, there's no way to exclude paths (in this case, /webform/*) from that behavior. However, for the Wodby image, you can work around it globally by setting the environment variable NGINX_STATIC_404_TRY_INDEX=1, which will send the request to index.php file if/when the "static" file request 404s.

I haven't tried it, and I'm allergic to changing a complex default value, but you can probably also use the NGINX_STATIC_EXT_REGEX env var for the Wodby image to update the default static file extension regex and remove CSS and JS files.

Note that the above fixes are only for the Wodby nginx image though — they are not a cure-all for all nginx setups.

After load-testing the above, this does present serious performance concerns. I load-tested our server with requests for several different types of requests:

• Valid Webform CSS/JS files, e.g. /webform/(css|js)/<real_form_id>/custom.(css|js)
• Paths that get routed to Webform but do not actually exist, e.g. /webform/(css|js)/<random_uuid>/custom.(css|js)
• Requests for CSS/JS files that do not get routed to Webform, e.g. /<random_uuid>/<random_uuid>.(css|js)

Again, if you enable the workaround I suggested above I strongly recommend enabling "fast 404" functionality instead of having Drupal render 404 pages. With a substantial number of requests (a few thousand per minute), even with fast 404 functionality, our CPU usage gets pegged near/at 100% — if Drupal is rendering "pretty" 404 pages, your website will likely become completely unusable. I would also strongly recommend using a CDN to cache 404s.

It didn't seem to make a difference whether the request got routed to Webform or was just some random garbage request that /index.php didn't know how to handle. Our website gets a lot of requests that would fall under the latter.

Ultimately though, it feels like any path is a risky approach. We don't load any of our forms via Ajax, so we never had any need for the fix that led to this bug. Is there any reason why custom CSS/JS can't be inlined into <style> and <script> tags, or why this behavior overall can't be made configurable? For example, allow the user to choose between the old routes, the Ajax-capable routes, or inline the scripts and styles, perhaps on a per-form basis.