Skip to content

Failed to load HTTP resource in live URL #23012

Closed

Description

@akilmakda

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Angular service worker application throws following error


Failed to HTTP in live url load resource : the server responded with a status of 504 (Gateway Timeout)

Expected behavior

It should not throw any exceptions

Minimal reproduction of the problem with instructions

Demo application on git below is the link
URL : https://github.com/akilmakda/PWA-not-work-in-HTTP

download application -> install npm -> build( ng build --prod) -> upload to any live server.

NOTE: in localhost, it works fine

screenshot from 2018-03-27 11-46-04

Environment


Angular version: 5.2.5


Browser:
- [ ] Chrome (desktop) version 65.0.3325.181
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 8.9.3  
- Platform: Linux

Activity

  1. added this to the needsTriage milestone on Mar 27, 2018
  2. jainanuj0812 commented on Mar 27, 2018

    @jainanuj0812
    Contributor

    Can you please share here, how you are using angular http service. It seems like you are facing issue due to some missing server-side configurations, something which is not related to angular.

  3. akilmakda commented on Mar 27, 2018

    @akilmakda
    Author

    @jainanuj0812 follow my uploaded application. In that application, I just set demo images three is in HTTPS and same three in HTTP when you set a refresh page https images are load but not HTTP images. You can check in console and Network tab of developer option.

    i set application in this server : https://ghostly-baud.000webhostapp.com/

  4. jainanuj0812 commented on Mar 27, 2018

    @jainanuj0812
    Contributor

    @akilmakda, You can't make a request to HTTP from the HTTPS based origin.

    https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

  5. gkalpak commented on Mar 27, 2018

    @gkalpak
    Member

    This seems to be caused by the fact that, while "passive mixed content" (like images) only produces a warning without a ServiceWorker, fetching it via a ServiceWorker results in an error. This applies to ServiceWorkers in general and is not specific to Angular's implementation.
    The link provided by @akoserwal above has more details on mixed content.

    As fas as I understand, the fact that fetching from within the ServiceWorker behaves differently than fetching without a ServiceWorker is a limitation of ServiceWorkers (see relevant discussions here, here, and here).

    One option for @angular/service-worker would be to choose not to handle this type of requests, but given that mixed content is insecure for users anyway, I would not be too keen on supporting it in @angular/service-worker 😈

    While fixing #20404 we can make sure that it is possible to specify URL patterns that won't be handled by the ServiceWorker, which would provide a work-around for your usecase (i.e. you could config the SW to ignore http: URLs and let the browser handle them).

    WDYT, @alxhub?

  6. gkalpak commented on Mar 27, 2018

    @gkalpak
    Member

    It turns out that the fix for #20404 cancannot provide a work-around for this issue.

  7. gkalpak commented on Mar 28, 2018

    @gkalpak
    Member

    So, the only fix/work-around I can think of is ignoring http: requests if the SW's scope is on https:. This can be checked synchronously and will avoid handling mixed content in the SW, which is currently not possible anyway.

  8. akilmakda commented on Apr 2, 2018

    @akilmakda
    Author

    @gkalpak 'ignoredUrlPatterns' not work for HTTP response. can you give any e.g how to ignore HTTP response.

    or any other way to ignore HTTP API response.

  9. gkalpak commented on Apr 2, 2018

    @gkalpak
    Member

    @akilmakda, I fixed my previous comment. I meant that #20404 cannot fix your usecase.
    As mentioned in #23012 (comment), one fix/work-around I can think of would be to not handle mixed content from the service worker (but that is a change that needs to be made to the SW; it is not something you can do yourself).

  10. 19 remaining items

  11. Krishna-Agrawal commented on Jan 18, 2019

    @Krishna-Agrawal

    @gkalpak any update on this?

  12. akilmakda commented on Jan 29, 2019

    @akilmakda
    Author

    @gkalpak any update?

  13. gkalpak commented on Jan 29, 2019

    @gkalpak
    Member

    I have a fix in #25994, but it is pending approval...

  14. eliraneliassy commented on Feb 27, 2019

    @eliraneliassy
    Contributor

    @gkalpak +1 here

  15. shabbir-dhangot commented on Mar 1, 2019

    @shabbir-dhangot

    @gkalpak It seems like this issue is faced by many of user but got stuck in approval process. I am also waiting for this fix for almost 6+ months.
    Kindly provide some tentative dates.

  16. gkalpak commented on Mar 4, 2019

    @gkalpak
    Member

    @shabbir-dhangot, hopefully this week 🎉 (based on #25994 (comment))

  17. shabbir-dhangot commented on Sep 5, 2019

    @shabbir-dhangot

    @gkalpak can you share document link how we can start using this?

  18. gkalpak commented on Sep 5, 2019

    @gkalpak
    Member

    Not sure what you mean @shabbir-dhangot. You don't have to do anything. This was a change in @angular/service-worker internals (it now ignores mixed content requests), you don't have to change anything in your app.

  19. angular-automatic-lock-bot commented on Oct 6, 2019

    @angular-automatic-lock-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.

  20. locked and limited conversation to collaborators on Oct 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions