Welcome to Vortx Community Forum, where you can ask questions and receive answers from the staff at Vortx and other members of the community.

If you had a user account on our previous forums website, you will need to register a new account here.

Learn more about...


Restarting.htm not sent with a Content-Type

v 9.2 MS.

Whenever my application goes into a restart, the file restarting.htm is displayed to users. This creates a problem on my homepage, though, because the URL doesn't have a file extension, so IIS doesn't match it to a MIME Type.

The result is that resetting.htm is delivered as the base-URL of my site, but with no Content-Type. When my CDN sees this, it interprets it as a text/plain asset for the page and caches that content for delivery as the only content on the page. I have a cache exclusion rule in place for the entire homepage, but that's not optimal.

Could anyone tell me where that restarting.htm is called up from? I can't seem to find it anywhere.
asked Jul 14, 2014 in MultiStore by Chris (3,685 points)

There is one reply on this http://forumarchive.vortx.com/threads/14713-restarting-htm.html post to the old forum, but I get a 404 when I try to access it.

2 Answers

+1 vote
Restarting.htm is referenced in the ASPDNSFApplication DLL, so you're not going to be able to specify the content type there unfortunately.

Out of curiousity, what content type are you wanting to specify?  I'm not familiar with a content type that would tell someone to ignore that content.  Is that something specific to your CDN?  We can look into adding a type or a way to specify it in the future if it's something that we can be sure will benefit (or at least not hurt) everyone.
answered Jul 17, 2014 by Vortx ScottS (13,500 points)
I need it to send the text/html content type. It's not so much to ignore the content, it's so that the content gets correctly identified. As it is right now, there is no content-type sent in the response header during application initialization.
Jan Simacek from Compunix has suggested having restarting.htm do a redirect to restarting.html. Since that would force the .html into the URL, it has the extra effect of making IIS serve up the text/html content-type header.

I've run this through my test environment and it seems to work quite nicely. I've got it queued for testing with the CDN.

I'll update this question with the results.
Unfortunately, this doesn't seem to work either, because the restarting.htm is still being picked up as an asset for the content to be loaded at the root URL.

Because of the way that the restarting.htm is hard-wired into the application, I have to do a meta refresh in order to redirect the page. I set it to a content of 0 so that it will fire straight away, but the same problem comes up.
0 votes
I've had to bounce this back to the license provider for my version of AspDotNetStorefront in order to get a fix. My organization bought a forked version of this software from Omnica as part of their Microsoft Dynamics AX integration package.

The behavior for sending the contents of restarting.htm is set in ASPDNSFApplication.dll, the source code for which is not provided (understandably) with the purchase of the software.

The trouble I'm encountering is that IIS doesn't have a filename in the URL, so it doesn't have anything to base a MIME type assignment to, and the content itself is being written in by the application at a very low level without the application explicitly assigning a Content-Type for the response.

Given the features available in IIS 7.5 and up, it would be better if this behavior was omitted so that the process can be handled outside of the application altogether. Barring that, the content should be sent with an explicity-set Content-Type.

I understand why the behavior can't be better exposed, but it doesn't make it acceptable.
answered Jul 28, 2014 by Chris (3,685 points)
My org bought their ASPDNSF license and software from a third party vendor that forked the product to work with their add-ons to Dynamics AX. I ended up having to lean on them to get a fix from Vortx, because none of us has the source code for the ASPDNSFApplication.dll, which is understandable.

The fix they provided was to change the parameters of the response that delivers the restarting.htm contents so that it would send with an HTTP Content-Type header of "text/html; charset=utf-8"

This appears to provide the missing content-type on that response, rather than rely on IIS to sort it out - which isn't possible when a filename and extension aren't present in the request URL.