Emitted HTML from XTP 23.7 suffix "?5580" to URLs

Hi,

My XTP version is Xara Designer Pro+ 23.7.0.68699 SL x64 Feb 21 2024.

When exporting a website of mine as HTML files to disk, I notice a strange behaviour as lots of emitted URLs has a ?5580-suffix to them, see the image below:
Attachment 134742

This of course leads to all sorts of trouble when the page tries to load, such as
"Refused to apply style from 'https://blaba/index_htm_files/xr_fonts.css?5580' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled."

Does anybody know what is going on? Where does "5580" come from? Is there a known remedy for this behaviour?

Best regards Bob

Quote:

---

Originally Posted by bobvoi

Hi,
My XTP version is Xara Designer Pro+ 23.7.0.68699 SL x64 Feb 21 2024.
When exporting a website of mine as HTML files to disk, I notice a strange behaviour as lots of emitted URLs has a ?5580-suffix to them, see the image below:
Attachment 134742
This of course leads to all sorts of trouble when the page tries to load, such as "Refused to apply style from 'https://blaba/index_htm_files/xr_fonts.css?5580' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled."

Does anybody know what is going on? Where does "5580" come from? Is there a known remedy for this behaviour?
Best regards Bob

---

Bob, the query-number (?5580) does not affect the CSS MIME type.
For instance, <link rel="stylesheet" href="index_html_files/xr_main.css?5580"> is legitimate. It does not include type="text/css", but I don't think that is the problem

It is more likely that fonts.css is missing altogether If you run https://blaba/index_htm_files/xr_fonts.css?5580 directly, do you get a 404 error?
If so, you have probably not uploaded part of the index_htm_files/ folder assets.

Why it is reporting type="text/html" is strange.

Without the actual URL to the site, I cannot help further.

The purpose of the query-number addition it to overcome the problems with frequently republishing as the time delay in getting the server to promulgate updates make the website appear funny for hours.

Acorn

Just digged a little further and found out that this seems to be a "cache-busting" technique ... somehow ...

Quote:

---

Originally Posted by bobvoi

Just digged a little further and found out that this seems to be a "cache-busting" technique ... somehow ...

---

That was my last sentence.

So we cross-posted.

It works as the browser sees it as a different file so it has never been cached.

Acorn

Thans for the prompt answer Acorn!

The file do exist, and if I ask for https://blaba/index_htm_files/xr_fonts.css I do get the css file in return. My backend-server is Domino so it might very well be that the problem lies there.

Hi Bob, I get a 'This site can’t be reached' from the link above. Is https://blaba suposed to have a .com or a co.uk or similar appendage to the url?

Quote:

---

Originally Posted by Egg Bramhill

Hi Bob, I get a 'This site can’t be reached' from the link above. Is https://blaba suposed to have a .com or a co.uk or similar appendage to the url?

---

Egg, I took it to be just made up to not reveal the actual site URL.

Acorn

Hi Egg. Acorn is right, I just hid the domain name a little. The important part was the cache-busting suffix "?5580"

I have now found out why the cache-busting suffix (such as "?5580") on js, css and woff urls don't work for me.

The explanation is related to my web server, which is HCL Domino. It expect the first parameter to be an "action" such as OpenDocument, OpenView, OpenAgent etc (interested persons can see more here) on Domino-related resources such as views, documents and agents. Urls to other resources shouldn't have any parameters.

In other words, the cache-busting technique, most probably only is used on resources that previously haven't had these suffixes, such as js, css, woff and other typical resource-files. The more I read about cache-busting, I see that people recommend all sorts of suffixes, such as ...somesheet.css?version=1.0, or ...somesheet.css?whatever. The concept is that the web server or proxy doesn't get a chance to cache the url between publishing sessions.

So, I hope Xara can publish more information about what url types (or file types) they suffix cache-busting numbers to, or even better, implement some way of telling a web-project that this particular project shouldn't emit cache-busting numbers at all. This can of course be via the UI, or by having a special HTMLHEAD-variable present in the page.

I will probably pursure the challenge myself as I have a preprocessor between Xara and Domino which I have made myself. This can be extended to strip away the cache-busting suffix (The function will probably be named BustTheCacheBust() :-). It would anyway be useful to know precicely which file types Xara emit cache-busts too.

Thanks for chiming in Acorn and Egg. I love the commitment in this group! I was pretty wild looking yesterday!

Attachment 134743

I have moved this thread to Web Design Chat

Quote:

---

Originally Posted by bobvoi

I have now found out why the cache-busting suffix (such as "?5580") on js, css and woff urls don't work for me.

The explanation is related to my web server, which is HCL Domino. It expect the first parameter to be an "action" such as OpenDocument, OpenView, OpenAgent etc (interested persons can see more here) on Domino-related resources such as views, documents and agents. Urls to other resources shouldn't have any parameters.

In other words, the cache-busting technique, most probably only is used on resources that previously haven't had these suffixes, such as js, css, woff and other typical resource-files. The more I read about cache-busting, I see that people recommend all sorts of suffixes, such as ...somesheet.css?version=1.0, or ...somesheet.css?whatever. The concept is that the web server or proxy doesn't get a chance to cache the url between publishing sessions.

So, I hope Xara can publish more information about what url types (or file types) they suffix cache-busting numbers to, or even better, implement some way of telling a web-project that this particular project shouldn't emit cache-busting numbers at all. This can of course be via the UI, or by having a special HTMLHEAD-variable present in the page.

I will probably pursure the challenge myself as I have a preprocessor between Xara and Domino which I have made myself. This can be extended to strip away the cache-busting suffix (The function will probably be named BustTheCacheBust() :-). It would anyway be useful to know precicely which file types Xara emit cache-busts too.

Thanks for chiming in Acorn and Egg. I love the commitment in this group! I was pretty wild looking yesterday!

Attachment 134743

---

Bob, rather than post-process, you could try adding the following type of detail into the Website Head:

Code:

---

<link rel="preload" href="index_html_files/xr_fonts.css" as="style" onload="this.onload = null; this.rel = 'stylesheet'"/>
<link rel="stylesheet" href="index_html_files/xr_main.css"/>
<link rel="preload" href="index_html_files/xr_text.css" as="style" onload="this.onload = null; this.rel = 'stylesheet'"/>
<script src="index_html_files/roe.js"></script>

---

In my case, I get both plain and query files loaded so it does work.

Acorn

For Background: https://www.talkgraphics.com/showthr...Xara-Resources