Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38902 > unrolled thread

IIS http.open "GET" error

Back to article view | Back to comp.lang.javascript

Contents

  IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 08:23 -0700
    Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 08:34 -0700
      Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 08:35 -0700
    Re: IIS http.open "GET" error John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-07 18:01 +0100
      Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 10:18 -0700
        Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 11:51 -0700
          Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 11:59 -0700
            Re: IIS http.open "GET" error "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-07 21:14 +0200
            Re: IIS http.open "GET" error Julio Di Egidio <julio@diegidio.name> - 2020-10-07 17:20 -0700
              Re: IIS http.open "GET" error Julio Di Egidio <julio@diegidio.name> - 2020-10-07 17:30 -0700
                Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 19:26 -0700
                  Re: IIS http.open "GET" error Frank Kozuschnik <franko@nurfuerspam.de> - 2020-10-08 10:38 +0200
                    Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-08 02:07 -0700
                  Re: IIS http.open "GET" error Julio Di Egidio <julio@diegidio.name> - 2020-10-08 05:49 -0700
                    Re: IIS http.open "GET" error "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-08 15:22 +0200
                      Re: IIS http.open "GET" error Julio Di Egidio <julio@diegidio.name> - 2020-10-08 06:30 -0700
    Re: IIS http.open "GET" error Arno Welzel <usenet@arnowelzel.de> - 2020-10-09 12:03 +0200
      Re: IIS http.open "GET" error Frank Kozuschnik <franko@nurfuerspam.de> - 2020-10-09 17:33 +0200
        Re: IIS http.open "GET" error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-10-09 18:14 +0200
          Re: IIS http.open "GET" error Frank Kozuschnik <franko@nurfuerspam.de> - 2020-10-09 19:38 +0200
            Re: IIS http.open "GET" error Julio Di Egidio <julio@diegidio.name> - 2020-10-11 03:30 -0700
        Re: IIS http.open "GET" error Arno Welzel <usenet@arnowelzel.de> - 2020-10-09 23:49 +0200
      Re: IIS http.open "GET" error Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-09 11:06 -0700
        Re: IIS http.open "GET" error Arno Welzel <usenet@arnowelzel.de> - 2020-10-09 23:52 +0200

Page 2 of 2 — ← Prev page 1 [2]

#38925

On Friday, 9 October 2020 19:38:39 UTC+2, Frank Kozuschnik  wrote:
> Thomas 'PointedEars' Lahn:
> > Frank Kozuschnik:
> > 
> >> "Just a file name" *is* a valid URL, typically relative to the URL of
> >> the current document.
> > 
> > In proper technical terms, it is a URI-reference.  It is NOT a URL.
> 
> My apologies for picking the outdated reference. RFC 1808 has indeed 
> become history, and the current RFC no longer uses the term "relative URL".
> 
> The WHATWG specification calls it a valid URL string.
> As such, it is still a valid argument for the open() method.

Please do not apologise, you were on the right track initially:
"URL" was correct here, you want a locator not just an identifier.
And, as for the relevant standard, it's indeed WHATWG's Living
Standard where you'll rather find no mention of URI anywhere.
Nor you'll find URI mentioned anywhere in the XHR API itself.

<https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest>

Julio

[toc] | [prev] | [next] | [standalone]

#38923

Frank Kozuschnik:

> Arno Welzel:
> 
>> 1) Make sure IIS works at all - put the file named SPASSKY.JCH to the
>> root directory and check that http://localhost/SPASSKY.JCH or
>> http://127.0.0.1/SPASSKY.JCH gives you the content of that file.
> 
> In a default setup, IIS will return a HTTP 404 error because the '.JCH' 
> suffix ("extension") is unknown. Adding the suffix to the "MIME Types" 
> list of the IIS configuration may help.

Is IIS really that stupid not to send the content of a file just because
it does not know the extension? One more reason not to use such crap. Go
and get NGINX or Apache - these are also available for Windows:

<https://httpd.apache.org/docs/2.4/platform/windows.html>

<http://nginx.org/en/docs/windows.html>



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38922

Den fredag 9 oktober 2020 kl. 12:03:37 UTC+2 skrev Arno Welzel:
> Jonas Thörnvall:
> 
> > Just installed IIS on the new computer, the SPASSKY.JCH game will
> > donwload from external internet service provider site but i can not
> > get it download from localhost 127.0.0.1  IIS server. "the webserver
> > start" it is just the get of file that fail on my server.
> > 
> > Is it just a filepath error or something else? The file resides at
> > root level in IIS server.
> > 
> > function loadFile(filePath) { var result = null; var xmlhttp = new
> > XMLHttpRequest(); xmlhttp.open("GET", filePath, false); 
> > xmlhttp.send(); if (xmlhttp.status==200) { result =
> > xmlhttp.responseText; } return result; }
> [...]
> > textFromFileLoaded=loadFile('SPASSKY.JCH'); 
> > parse(textFromFileLoaded)
> > 
> > loadsave.js:62 Uncaught TypeError: Cannot read property 'split' of
> > null at parse (loadsave.js:62) at chessInit (gameengine.js:14) at
> > (index):130
> 
> 1) Make sure IIS works at all - put the file named SPASSKY.JCH to the
> root directory and check that http://localhost/SPASSKY.JCH or
> http://127.0.0.1/SPASSKY.JCH gives you the content of that file.
> 
> 2) XHR does not load "files" it will send a HTTP request for an *URL*.
> Also see
> <https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/open>.
> Therefore you should also put the URL there and not just a file name.
No it does not.
> 3) Add error handling - there are many reasons why a request can fail.
> Assuming a function which fetches data via XHR will always work and
> always return data in a certain way will eventually cause security
> problems. If loadFile() can return null then handle this case and don't
> assume in parse() that there will always be a valid content.
Well the fetch is working as soon you rename it to SPASSKY.TXT
> -- 
> Arno Welzel
> https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38924

Jonas Thörnvall:

> Den fredag 9 oktober 2020 kl. 12:03:37 UTC+2 skrev Arno Welzel:
[...]
>> 3) Add error handling - there are many reasons why a request can fail.
>> Assuming a function which fetches data via XHR will always work and
>> always return data in a certain way will eventually cause security
>> problems. If loadFile() can return null then handle this case and don't
>> assume in parse() that there will always be a valid content.
> Well the fetch is working as soon you rename it to SPASSKY.TXT

Then either configure IIS properly or use Apache or NGINX instead.
Neither Apache or NGINX will return HTTP 404 for an "unknown" extension.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web