angular-cli: Server returns 404 when performing HEAD request

OS?

macOS Sierra 10.12.3

Versions.

1.0.0-rc.0

Repro steps.

Perform HEAD request to the spawned server by ng serve using (cURL, fetch, Angular HTTP, XHR) and it will automatically return 404.

Mention any other details that might be useful.

When the URL provided is: http://localhost:4200/assets/img/ui/logo.png (assuming it exists) it returns 404. But when the URL provided is: http://localhost:4200/src/assets/img/ui/logo.png it returns 200.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 3
Comments: 15 (4 by maintainers)

Most upvoted comments

@exequiel09 It might be that the webpack-dev-server we use in ng serve does not support HEAD requests as configured. If that’s an option we can include it.

@Daedalon the change I mentioned prevented files that were not in a build from being served from ng serve. Files that are on disk but are not included in a build should not be served because they are not part of the files that go in dist/ after ng build. That is not a breaking change - you were just relying on a bug and we fixed that bug.

filipesilva on Mar 18, 2017

@filipesilva perform a curl HEAD request. I attached screenshots of what’s happening. Performing GET request works but using HEAD request fails. I use HEAD request to check if the file is really present on the assets directory.

curl --head http://localhost:4200/assets/<path_to_file>

Head request without src before the assets folder

Head request with src before the assets folder

exequiel09 on Mar 15, 2017

that change should not be reverted. Only assets that are part of a build should be served.

@filipesilva Could you clarify what you mean? The URLs for assets are broken due to this change and unfortunately I didn’t yet understand what your sentence means in this context.

The alternatives I see are:

Every affected user updates the URLs to all assets to reflect this non-announced breaking change. The URLs that work around this change in NG-CLI’s server will probably not work in production. 👎
This non-announced breaking change is reverted and the URLs will work the same as they have until this breakup. 👍

Daedalon on Mar 15, 2017