Pages with .html respond with 301 Moved Permanently causing service workers to fail.
If a page is requested that has .html at the end then the response is a 301 Moved Permanently. And if this is stored in cache with the help of a service worker then reading it from cache on subsequent fetch event with cache.match() doesnt work as Chrome throws following error
The FetchEvent for "http://localhost:5000/modules/tester.html" resulted in a network error response: a redirected response was used for a request whose redirect mode is not "follow".
The same thing happens to me for an argh.html file I have in the directory being served:
$ curl -i localhost:5000/argh.html
HTTP/1.1 301 Moved Permanently
Location: /argh
Date: Wed, 13 Nov 2019 22:30:10 GMT
Connection: keep-alive
Transfer-Encoding: chunked
If this is an intentional default, I think this tool has become too opinionated.
I was just about to put in an issue but this seems like it might be related: I've noticed that when I use serve to host codecov HTML reports, files generated with a path like http://some.url/route/to/src/SomeComponent.jsx.html get redirected to the same path with the .html extension missing (in this case, http://some.url/route/to/src/SomeComponent.js) resulting in a 401 message being displayed.
I haven't used a tool like Curl to examine the response and see if I'm getting a 301 in response to the original request - that will be my next step, but I'll follow this in case this also resolves that issue
Hey @uchilaka can you provide a full directory structure (or at least the immediate parent and siblings list) of that specific component file you are mentioning.
I was just about to put in an issue but this seems like it might be related: I've noticed that when I use
serveto hostcodecovHTML reports, files generated with a path likehttp://some.url/route/to/src/SomeComponent.jsx.htmlget redirected to the same path with the.htmlextension missing
@uchilaka As the same, I also have a project having PdfJs and build the source with vue-cli but the pdfjs viewer is a static html file(viewer.html).
The problem is that when I access to the static html file (ex. viewer.html) through 'serve' like 'localhost:8080/assets/pdfjs/viewer.html', the extnsion '.html' is missing - redirected to 'localhost:8080/assets/pdfjs/viewer' and it shows the page. this happens only when using 'serve' :(
@r0mflip
- root
- assets
- pdfjs/viewer.html
- js
- css
- index.html
- assets
I'm having the same problem. When trying to access a HTML file at http://localhost:5000/somefile.html it get's redirected to http://localhost:5000/somefile. I'm running serve with npx serve -s build. Has anyone found a solution for this?
Hasn't there been a solution yet ?
It seems like a conscious design choice, so I think someone has to fork the tool and remove the feature, or PR a --no-smartass-redirects switch disabling it :laughing:
Hasn't there been a solution yet ?
Sorry for my late response. I use another serve tool like the minimum apache server served with krpano tools on the following link or you can use web serve : chrome extension
I gave up keeping using 'serve' because of this feature in the project in which requires opening self host files.
Hasn't there been a solution yet ?
Sorry for my late response. I use another serve tool like the minimum apache server served with krpano tools on the following link or you can use web serve : chrome extension
I gave up keeping using 'serve' because of this feature in the project in which requires opening self host files.
hahaha, me too, gave up and wrote the custom script
I've just published a fork called berve that puts this behavior behind a --clean-urls switch that defaults to off: https://github.com/papandreou/serve/tree/berve
for anyone stumbling upon this issue, using a serve.json file with :
{
"cleanUrls": false
}
seems to do the trick and stops redirecting /myFile.html to /myFile
see #404
(nice issue number btw 😄 )
for anyone stumbling upon this issue, using a
serve.jsonfile with :{ "cleanUrls": false }seems to do the trick and stops redirecting
/myFile.htmlto/myFilesee #404
(nice issue number btw 😄 )
this did the trick for me, tks!
make sure serve.json is copied to the root of the folder being served, before launching serve