Serve: Pages with .html respond with 301 Moved Permanently causing service workers to fail.

[bjdash]

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".

[papandreou]

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.

[uchilaka]

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

[r0mflip]

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.

[kabkee]

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

@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
  
  

[juhanakristian]

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?

[1xiyu]

Hasn't there been a solution yet ？

[papandreou]

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:

[kabkee]

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.

[1xiyu]

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

[papandreou]

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

[t-fritsch]

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 😄 )