Angular-cli: Server returns 404 when performing HEAD request

[exequiel09]

OS?

macOS Sierra 10.12.3

Versions.

1.0.0-rc.0

Repro steps.

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

[evelbulgroz]

I also have this issue. Easy to verify using a stock project created with ng new ... . Totally breaks my dev workflow.

[evelbulgroz]

Some more info: My problem relates to a static /content/ folder with a couple of large image files. Adding this to assets causes the build to fail. So can't go down that route.

[evelbulgroz]

Fixed: Moved some hidden .originals folders with very large original artwork out of ´src/content/´ to a separate folder in the project root. Traced it down to a failure in webpack after ejecting the webpack config.

[Daedalon]

Applies to all requests, not just HEAD: #5064

The issue seems to be a breaking change of looking for assets under a different path than before (now requiring src/ in the path). Should be reverted.

[filipesilva]

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

I can't seem to repro this. I put an image in assets/, ran ng serve and tried to get that image via cURL and it worked:

kamik@T460p MINGW64 /D/sandbox/master-project (master)
$ ls src/assets/
execute.jpg

kamik@T460p MINGW64 /D/sandbox/master-project (master)
$ curl http://localhost:4200/assets/execute.jpg
 Ï Ó ►JFIF ☺☺☺ H H   █ C ♣♥♦♦♦♥♣♦♦♦♣♣♣☼♂♂       ♀◄☼↕↕◄☼◄◄‼■∟↨‼¶→§◄◄↑!↑→↔↔▼▼▼‼↨"$"▲$∟▲▼▲ █ C☺♣♣♫▲¶◄¶▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲ └ 8 8♥☺" ☻◄☺♥◄☺ ─ ¶"2Qaqí§■$3üæÆ ─ →☺ ☻♥☺☺           ♣♠♥♦☻☺ ─ 0◄ ☺☻♣☻♦♣☻☺      ☺☻◄ ♥♦!1♣↕♠AQü‼"æí­aq¶#2r▒┴Ðß ┌ ♀♥☺ ☻◄♥◄ ? ╦Wd9sªTjê←Öĵ▲uÃrѼÝ╔$‗Ñ↕rI¯I¯t¢§¢Ù rr →Øç&d←ö
↑Tn╣)SÛp¥Ô→B©*J┬UÁHO    └ÕDd☼æ→®kÆnj³¿┤Z}>×XèéÂíÊb(2Æá  Q↓╬¯;ôõ²§═4╣ÆUÒN ♥ƒ¹÷ë§ÝJ骣RÊ%JÏ@I= ☺Ê9¯g╗▲╠#ûìJº╦n┐Q£®uv^§¸/☼Mi‼fE1#QñªÜ╩(èïwP♫¹­£rOı▀Ø9^6MìaXÈHw
çFº{´n╔ [─©ä♠╩╬BFU╔┴Ój<F╣nÞ¿â☻ù◄#lt║ÿ±æÓr│¾Q¹£ƒÍu1Vºª▀á╬Àd═j}^pCıA      AÈAê╔▀éí±+*ã@ÝÃ▀M¶  KÛTjL→ıÃ→←Û½▓[ñËR┤║Ò╦q#`Ãd×A*▼O∟¾ìE6Á☺þ♂ù‗ôÊÎ☻┘.ÃÑ­a`K l§à█↕òCºã¬Poj╠╦fDyîJb[q∟Æ╦è % ■êPPrãI♦◄úM▓¯→╝iòz}☺╚ý@º└üIÖUì↨{Ä©╩vö0☼♣ı)[J╣└╔¹↔→Åm=Gµ-d↕─üî♫áæf,KçÄÜjlæhóõ█‗"[ýV%);↔É×èwØÃìßC▲˹Íé■ÖÝ╚mȪ_À#àTøq☺ÊÔÊ?ÜI  m v╩I╚þ;è>·«þR¬‼ÝhO8ýq♫→ÐËióKçv@¦Ò­<¸ı█└UúaÐ=;îÔR¾i5
"ÖF3n¬├«S®Hè─$IZ☺ûªÂ³ô↔ õ)j$§Æ A8ãï*▒♂R☻»¾²┐h@¼ÊU!;ôoש¨ÿ]¶Ì♦+>\¸º├Mrlµ=¼ÿ-2§↔@ö¿ìÚ9}N%→∟→O╣§:õ¡Ïè¡»■Q±K`ÄFÕ‼¹█  luxß(m)t-J╚♥Â{↕X¾ªj
♦¿‼õqº9w\ƒe$[■
rÁ!▓äØ©‗ ╬☼Ï♫┌ìtôÛªÖèûÉý¯óq¶■§´☺LP┐╠Áá↨:½%
→nçk╚╗¼ÙÜ▄2¶^ª)èö↓2V☻☻Â)+B▄=üBH♥Ç1Æp4k┌üY%[ecÂI'£9­┌8nu):ôxÅ╠‼f♀═f¸w·Dá6┬+×ñArZJ)Èõ¬í)ò¼ä→$'<ÒÙ)8‗☻çlÚ╩‗aÛÁZt¶çzsVJKÃ‗8¯♠  xã×¼♂rU↕ôqHÿË.U'╔÷ÕM$♣$¶'rr8Ãsã1¿[á░
┤ª$E!L░0JG┼Gîü¸▼ƒ:Hȵ¬\Öog┐|☼@  ¯▼0nv░ku5LM└☺#á↓'╣ ?6èZ│→←RRËêT░àò┼Ú↕î`³ë¾ãGÙÝ»¡2Ñ´Ò.$Ãñ¡®♥¨C╬‼Ç        ↑╩~8Ã|±°È¡nö‗∟█◄ÇÞ╔%    ♦®YÓp<wÈjXïE}fºRnûH┌ñ©:«'=░Ïõd∟‗8¤þGt¬ÖsÆ7Å×ÐwTº‼ñ┤º*8µyr┐▀♣¹┬¦RØ&å┌N♥▒VÆ¿Æ °< ßC?lîì)èÒ¡V7Ä©ÉÊ:╩R░☺∟£w³cNùW®¶┤ÐWKºS←v3¡ÔBÛ↓t)[@╩►1Ä8╔>♠5M"Òm║£╣▲¦n°HH▀ìá♫▀▄Þ¶¶Üòâ)╚HÕıÃ╬ð¢ÑMFÅ!H¼    Bª¿☼0♦öm♫@*g²Ï┤hU»ê÷ØÀTÁÔJdUÛk┼YµWö▓äú☻"H╬Õ²[È8←èy9┴¼═S«Jû┘e¦¢"¢╚l☺äÓ`☺ÃlhıôB'ؾ¾¸─♥ù─¬ÊÉ$iç╦Æóø®]rX3 :f¯NÛæÛÁómX¶Þı­B┴rZ►┌ʹàjQR☼Sn 9Iþ'♦qî→■Ô§EÿNû █ÕÃ6éçeI╩H¤'b >1§hÐñZÜ9KÜ7¦â♂Ó☺→Å♫Þ¶Jûò¼§§§‼v╗²←¦ß↕¢Û§├Q♂lHD&öyj↕♥C  CÕÄ{‼¬‗½P}■¥úÆW┐Æ þ■thÐZ↓↕┴ã"µÂúK'├º‗♥k ♫@╠G░ÞøLvù↔¥£Áá¯qım+┴õv╔Êt¸²│ïmiJûò¶ß*╩r♫☼>thË%▼ÆjÕîX¸1ô±→ìE♣=T¤ÈÛG@╔ ĸ.yÃ←↕▲┌▀U┼∟% gƒ ☼:4hÐ↑JÅ ┘

[exequiel09]

@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>

[Daedalon]

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:

1) 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. :-1:
2) This non-announced breaking change is reverted and the URLs will work the same as they have until this breakup. :+1:

[exequiel09]

@Daedalon i agree to the points presented especially number 1 where it would break everything that depends on assets path since performing ng build does not include src folder in the generated dist folder.

[filipesilva]

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

[anaerobic]

FWIW, I was able to reproduce this using the Web Technology Notifier chrome extension... I disabled the extension and the HEAD request was no longer being made.

[mgechev]

If you still hit this problem, you can explore customizing your build with ngx-build-plus. Alternatively, we can close the issue?

[evelbulgroz]

No longer relevant to me, thanks.

[mgechev]

Thanks for the response!

[itsLucario]

This issue is there and I did not find any simple ways of achieving it. Kindly reopen this issue

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}