Corrupt clientraw files

Good catch Wim :slight_smile: One more possible clue, it only returns that funky page for .txt files, for other extensions it shows the regular IIS 404 page - http://www.stuvebakken.no/wddata/blah.html so there is something else odd about the server setup.

I agree.
Even if I remove/delete the clientraw.txt file I get the same answer from inside (as well as outside) the web server (eExQQQMKF11NQQ8bO1JeF0oaSE6bLjMTF0uaQP8QWRQj).
Also, the server provides the same answer whatever *.txt I request.

Maybe your server is now set up to auto block any .txt files? If it worked before the question has to be “what changed?”

Nothing happened at all. Only changes had been the dayly snow depth update in WD. But that has been done during the season for many years.
For info; I just also reinstalled WDL (just overwrite), however no other result

It is not only you who can make changes.
Also your provider can do that.
Or someone (Microsoft’s automatic update) installed a new version of IIS which maybe has a new “feature”.

You will have to check that also.

Wim

Strange…
The web server is my own in house machine, controlled by me only, running both WD as well as publishing the www.stuvebakken.no (where WDL is located).

Maybe you could test WDL without the URL’s for the files

  1. make a copy of your current /wddata/wdlconfig.xml
  2. remove the lines with the links to the clientraw files as they are not needed
<clientraw>http://www.stuvebakken.no/wddata/clientraw.txt</clientraw>
<clientrawextra>
http://www.stuvebakken.no/wddata/clientrawextra.txt
</clientrawextra>
<clientrawdaily>
http://www.stuvebakken.no/wddata/clientrawdaily.txt
</clientrawdaily>

and see what happens then.
If WDL runs OK you can better post a new question about IIS and this strange 404 message for all (existing and not-existing) .txt files.
That will interest a different group of readers then this “clientraw” question.

Wim

Unfortunately most of the server expertise here is Apache rather than IIS :frowning:

Unfortunately most of the server expertise everywhere is Apache rather than IIS :frowning:

But if the WDL problem is solved here first, then:
one can google for “IIS deny access to certain file-types” and check if one of those solutions is the culprit
and / or one can google for IIS forums and post the question on another forum

But please, always report back if a solution is found.

Wim

Certainly worth a try but I’m doubting there is an actual “WDL problem”, seems to me the server is determined not to serve any .txt file and I doubt WDL can overcome that :frowning:

I think this IIS will not serve any external txt file when addressed by the full url.

When not using the URL location in the wdlconfig.xml, WD-Live looks for the file in the current folder and will not use more a more complicated file-access using http://

I think, I hope, maybe a little doubt here and there :roll:

===
If this not works, we will have to upload the clientraw files as .htm and set the file locations in the config file to the .htm files also.
That will work 99% sure, but it involves more work at the WD part.

Wim

Good points :slight_smile: I also wondered about trying the alternate extension idea, I was thinking of a junk extension rather than a recognized filetype.

Cannot say I quite understand all of the help as discussed…
I removed the pointers from the wdlconfig file in WDL/wddata.
Strangely enough the files continous to generate in the wddata directory and the web display is just as wrong.
I am lost. Should I consider a complete reinstall of both WD and WDL?

In my opinion it is not a WD or WDL issue, it is a server side issue caused by IIS. As Wim suggested, find an IIS support group/forum and ask about IIS not wanting to serve .txt files.

Have me excused, but what is this IIS?
The web presentation on this server has worked for years …

IIS is the common product-name for your web presentation server and its name is also shown on any normal 404 message, such as Niko used as an example http://www.stuvebakken.no/wddata/blah.html

Wim

Thanks.
Should I use a different server?

You say it has worked well for you for a long time. If WDL on IIS worked before, there’s no reason why it shouldn’t be fixed to work again. In your position I would think very carefully before throwing away that experience and starting over with something quite different.

Update: Looks like you are running very old version 6.0 of IIS which probably means you are running Windows Server 2003 8O Current IIS version is 10.0 so maybe moving to an up-to-date server software wouldn’t be such a bad idea.

I did find this Microsoft Support article which may point you in the right direction.

Hmmmm…

If I do like Wim says (over), i.e. remove the pointers to clientraw files in wdlconfig (in wddata directory), the WDL actually starts and works from “inside”; starting it from index.html in the wddata directory. Strangely it seems that if I restore the wdlconfig (with the pointers), and then try to start, WDL returns same error message.

…hmmmm

So Wim is correct “When not using the URL location in the wdlconfig.xml, WD-Live looks for the file in the current folder and will not use more a more complicated file-access using http://” :smiley: