Web manifest is not accessible after forcing SSL
I recently started forcing HTTPS and non-WWW forms for the URL of my React PWA through the .htaccess file, but this is apparently preventing certain applications (such as pwabuilder.com) from accessing public files of the app, such as its web manifest. That said, there are certain applications, such as Chrome mobile that allow me to access the manifest. How can I make it always accesible?
My .htaccess file is structured like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://aurora.igloo.ooo%{REQUEST_URI} [L,NE,R=301]
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
RewriteRule ^ /index.html [L]
</IfModule>
The file that pwabuilder.com can't access is hosted on https://aurora.igloo.ooo/manifest.json
reactjs apache .htaccess progressive-web-apps manifest.json
|
show 1 more comment
I recently started forcing HTTPS and non-WWW forms for the URL of my React PWA through the .htaccess file, but this is apparently preventing certain applications (such as pwabuilder.com) from accessing public files of the app, such as its web manifest. That said, there are certain applications, such as Chrome mobile that allow me to access the manifest. How can I make it always accesible?
My .htaccess file is structured like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://aurora.igloo.ooo%{REQUEST_URI} [L,NE,R=301]
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
RewriteRule ^ /index.html [L]
</IfModule>
The file that pwabuilder.com can't access is hosted on https://aurora.igloo.ooo/manifest.json
reactjs apache .htaccess progressive-web-apps manifest.json
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
There doesn't seem to be anything "wrong" with your.htaccessfile that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?
– MrWhite
Jan 5 at 22:53
The response fromhttps://aurora.igloo.ooo/manifest.jsoncomes back from "nginx/1.2.1", not Apache?
– MrWhite
Jan 7 at 23:01
1
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38
|
show 1 more comment
I recently started forcing HTTPS and non-WWW forms for the URL of my React PWA through the .htaccess file, but this is apparently preventing certain applications (such as pwabuilder.com) from accessing public files of the app, such as its web manifest. That said, there are certain applications, such as Chrome mobile that allow me to access the manifest. How can I make it always accesible?
My .htaccess file is structured like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://aurora.igloo.ooo%{REQUEST_URI} [L,NE,R=301]
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
RewriteRule ^ /index.html [L]
</IfModule>
The file that pwabuilder.com can't access is hosted on https://aurora.igloo.ooo/manifest.json
reactjs apache .htaccess progressive-web-apps manifest.json
I recently started forcing HTTPS and non-WWW forms for the URL of my React PWA through the .htaccess file, but this is apparently preventing certain applications (such as pwabuilder.com) from accessing public files of the app, such as its web manifest. That said, there are certain applications, such as Chrome mobile that allow me to access the manifest. How can I make it always accesible?
My .htaccess file is structured like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://aurora.igloo.ooo%{REQUEST_URI} [L,NE,R=301]
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
RewriteRule ^ /index.html [L]
</IfModule>
The file that pwabuilder.com can't access is hosted on https://aurora.igloo.ooo/manifest.json
reactjs apache .htaccess progressive-web-apps manifest.json
reactjs apache .htaccess progressive-web-apps manifest.json
edited Dec 30 '18 at 10:04
Samuele Dassatti
asked Dec 30 '18 at 0:12
Samuele DassattiSamuele Dassatti
4412
4412
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
There doesn't seem to be anything "wrong" with your.htaccessfile that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?
– MrWhite
Jan 5 at 22:53
The response fromhttps://aurora.igloo.ooo/manifest.jsoncomes back from "nginx/1.2.1", not Apache?
– MrWhite
Jan 7 at 23:01
1
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38
|
show 1 more comment
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
There doesn't seem to be anything "wrong" with your.htaccessfile that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?
– MrWhite
Jan 5 at 22:53
The response fromhttps://aurora.igloo.ooo/manifest.jsoncomes back from "nginx/1.2.1", not Apache?
– MrWhite
Jan 7 at 23:01
1
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
There doesn't seem to be anything "wrong" with your
.htaccess file that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?– MrWhite
Jan 5 at 22:53
There doesn't seem to be anything "wrong" with your
.htaccess file that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?– MrWhite
Jan 5 at 22:53
The response from
https://aurora.igloo.ooo/manifest.json comes back from "nginx/1.2.1", not Apache?– MrWhite
Jan 7 at 23:01
The response from
https://aurora.igloo.ooo/manifest.json comes back from "nginx/1.2.1", not Apache?– MrWhite
Jan 7 at 23:01
1
1
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38
|
show 1 more comment
2 Answers
2
active
oldest
votes
aurora.igloo.ooo has a strange server and preventing some requests from accessing manifest.json.
First time when I clicked your link, I saw the manifest.json. Then I called the main-page by removing the filepath, clicked back in browser-history to see the manifest again and got this shown (with http-response-code 200):

Looking at it in the network-console it's still getting more confusing but also leads to the source of the error:

It's complaining about missing enabling of javascript, so they make some weird things with javascript and probably some hidden redirect too (else the response code would be 3xx). Perhaps they never want the manifest being accessed from outside and it's not configured properly and can be seen under some conditions.
I don't have a quick solution for your problem but it's quite obvious that some clients can't access the manifest and you've to search for another solution. If you're working for aurora.igloo.ooo you've to speak with the frontend-developers and/or server-admins to change something, else you've to offer your own manifest-file. Also it's possible that they offer a solution for the problem, but for that you've either to have access to some FAQ or knowledge-base or you've to contact the support.
add a comment |
Having read about manifest-files on desktop it would force another user-experience and at least in chrome change the complete window. While that might be cool for some special pages it also could be confusing.
Here are the three links I read about it:
- https://developers.google.com/web/fundamentals/web-app-manifest/
- https://developers.google.com/web/fundamentals/app-install-banners/
- https://developers.google.com/web/progressive-web-apps/desktop
My assumption is that aurora.igloo.ooo never want to break with common browsing experience by showing a special app-window on desktop, therefore they prevent the manifest from loading properly on desktop.
I just read the first time about it, so the technical behavior like I understood it might be wrong or it's not the complete technical background.
At least the impression I got is that on desktop it should be considered twice if a website shall run as web-app. If you choose this solution nevertheless, you probably need still find more information about it but the links I posted might be a good start and offer still further details and links.
Another reason to decide against a web-app for desktop might be the compatibility between browsers, as support of technical options is very differing:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json#Browser_compatibility
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53974325%2fweb-manifest-is-not-accessible-after-forcing-ssl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
aurora.igloo.ooo has a strange server and preventing some requests from accessing manifest.json.
First time when I clicked your link, I saw the manifest.json. Then I called the main-page by removing the filepath, clicked back in browser-history to see the manifest again and got this shown (with http-response-code 200):

Looking at it in the network-console it's still getting more confusing but also leads to the source of the error:

It's complaining about missing enabling of javascript, so they make some weird things with javascript and probably some hidden redirect too (else the response code would be 3xx). Perhaps they never want the manifest being accessed from outside and it's not configured properly and can be seen under some conditions.
I don't have a quick solution for your problem but it's quite obvious that some clients can't access the manifest and you've to search for another solution. If you're working for aurora.igloo.ooo you've to speak with the frontend-developers and/or server-admins to change something, else you've to offer your own manifest-file. Also it's possible that they offer a solution for the problem, but for that you've either to have access to some FAQ or knowledge-base or you've to contact the support.
add a comment |
aurora.igloo.ooo has a strange server and preventing some requests from accessing manifest.json.
First time when I clicked your link, I saw the manifest.json. Then I called the main-page by removing the filepath, clicked back in browser-history to see the manifest again and got this shown (with http-response-code 200):

Looking at it in the network-console it's still getting more confusing but also leads to the source of the error:

It's complaining about missing enabling of javascript, so they make some weird things with javascript and probably some hidden redirect too (else the response code would be 3xx). Perhaps they never want the manifest being accessed from outside and it's not configured properly and can be seen under some conditions.
I don't have a quick solution for your problem but it's quite obvious that some clients can't access the manifest and you've to search for another solution. If you're working for aurora.igloo.ooo you've to speak with the frontend-developers and/or server-admins to change something, else you've to offer your own manifest-file. Also it's possible that they offer a solution for the problem, but for that you've either to have access to some FAQ or knowledge-base or you've to contact the support.
add a comment |
aurora.igloo.ooo has a strange server and preventing some requests from accessing manifest.json.
First time when I clicked your link, I saw the manifest.json. Then I called the main-page by removing the filepath, clicked back in browser-history to see the manifest again and got this shown (with http-response-code 200):

Looking at it in the network-console it's still getting more confusing but also leads to the source of the error:

It's complaining about missing enabling of javascript, so they make some weird things with javascript and probably some hidden redirect too (else the response code would be 3xx). Perhaps they never want the manifest being accessed from outside and it's not configured properly and can be seen under some conditions.
I don't have a quick solution for your problem but it's quite obvious that some clients can't access the manifest and you've to search for another solution. If you're working for aurora.igloo.ooo you've to speak with the frontend-developers and/or server-admins to change something, else you've to offer your own manifest-file. Also it's possible that they offer a solution for the problem, but for that you've either to have access to some FAQ or knowledge-base or you've to contact the support.
aurora.igloo.ooo has a strange server and preventing some requests from accessing manifest.json.
First time when I clicked your link, I saw the manifest.json. Then I called the main-page by removing the filepath, clicked back in browser-history to see the manifest again and got this shown (with http-response-code 200):

Looking at it in the network-console it's still getting more confusing but also leads to the source of the error:

It's complaining about missing enabling of javascript, so they make some weird things with javascript and probably some hidden redirect too (else the response code would be 3xx). Perhaps they never want the manifest being accessed from outside and it's not configured properly and can be seen under some conditions.
I don't have a quick solution for your problem but it's quite obvious that some clients can't access the manifest and you've to search for another solution. If you're working for aurora.igloo.ooo you've to speak with the frontend-developers and/or server-admins to change something, else you've to offer your own manifest-file. Also it's possible that they offer a solution for the problem, but for that you've either to have access to some FAQ or knowledge-base or you've to contact the support.
edited Jan 8 at 1:52
answered Jan 7 at 11:55
DavidDavid
2,12122028
2,12122028
add a comment |
add a comment |
Having read about manifest-files on desktop it would force another user-experience and at least in chrome change the complete window. While that might be cool for some special pages it also could be confusing.
Here are the three links I read about it:
- https://developers.google.com/web/fundamentals/web-app-manifest/
- https://developers.google.com/web/fundamentals/app-install-banners/
- https://developers.google.com/web/progressive-web-apps/desktop
My assumption is that aurora.igloo.ooo never want to break with common browsing experience by showing a special app-window on desktop, therefore they prevent the manifest from loading properly on desktop.
I just read the first time about it, so the technical behavior like I understood it might be wrong or it's not the complete technical background.
At least the impression I got is that on desktop it should be considered twice if a website shall run as web-app. If you choose this solution nevertheless, you probably need still find more information about it but the links I posted might be a good start and offer still further details and links.
Another reason to decide against a web-app for desktop might be the compatibility between browsers, as support of technical options is very differing:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json#Browser_compatibility
add a comment |
Having read about manifest-files on desktop it would force another user-experience and at least in chrome change the complete window. While that might be cool for some special pages it also could be confusing.
Here are the three links I read about it:
- https://developers.google.com/web/fundamentals/web-app-manifest/
- https://developers.google.com/web/fundamentals/app-install-banners/
- https://developers.google.com/web/progressive-web-apps/desktop
My assumption is that aurora.igloo.ooo never want to break with common browsing experience by showing a special app-window on desktop, therefore they prevent the manifest from loading properly on desktop.
I just read the first time about it, so the technical behavior like I understood it might be wrong or it's not the complete technical background.
At least the impression I got is that on desktop it should be considered twice if a website shall run as web-app. If you choose this solution nevertheless, you probably need still find more information about it but the links I posted might be a good start and offer still further details and links.
Another reason to decide against a web-app for desktop might be the compatibility between browsers, as support of technical options is very differing:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json#Browser_compatibility
add a comment |
Having read about manifest-files on desktop it would force another user-experience and at least in chrome change the complete window. While that might be cool for some special pages it also could be confusing.
Here are the three links I read about it:
- https://developers.google.com/web/fundamentals/web-app-manifest/
- https://developers.google.com/web/fundamentals/app-install-banners/
- https://developers.google.com/web/progressive-web-apps/desktop
My assumption is that aurora.igloo.ooo never want to break with common browsing experience by showing a special app-window on desktop, therefore they prevent the manifest from loading properly on desktop.
I just read the first time about it, so the technical behavior like I understood it might be wrong or it's not the complete technical background.
At least the impression I got is that on desktop it should be considered twice if a website shall run as web-app. If you choose this solution nevertheless, you probably need still find more information about it but the links I posted might be a good start and offer still further details and links.
Another reason to decide against a web-app for desktop might be the compatibility between browsers, as support of technical options is very differing:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json#Browser_compatibility
Having read about manifest-files on desktop it would force another user-experience and at least in chrome change the complete window. While that might be cool for some special pages it also could be confusing.
Here are the three links I read about it:
- https://developers.google.com/web/fundamentals/web-app-manifest/
- https://developers.google.com/web/fundamentals/app-install-banners/
- https://developers.google.com/web/progressive-web-apps/desktop
My assumption is that aurora.igloo.ooo never want to break with common browsing experience by showing a special app-window on desktop, therefore they prevent the manifest from loading properly on desktop.
I just read the first time about it, so the technical behavior like I understood it might be wrong or it's not the complete technical background.
At least the impression I got is that on desktop it should be considered twice if a website shall run as web-app. If you choose this solution nevertheless, you probably need still find more information about it but the links I posted might be a good start and offer still further details and links.
Another reason to decide against a web-app for desktop might be the compatibility between browsers, as support of technical options is very differing:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json#Browser_compatibility
answered Jan 8 at 1:56
DavidDavid
2,12122028
2,12122028
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53974325%2fweb-manifest-is-not-accessible-after-forcing-ssl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can you share your .htaccess, and exact path to one of the public files that are not accessible?
– Dusan Bajic
Dec 30 '18 at 8:44
I edited my question with the .htaccess file
– Samuele Dassatti
Dec 30 '18 at 10:04
There doesn't seem to be anything "wrong" with your
.htaccessfile that would prevent these applications from accessing these files. Just as you can access that file with any browser, so should the other application. ...Unless perhaps these other applications are not requesting the canonical URL (HTTPS + www) and do not follow redirects?! You should check your server's access log to see what requests are hitting your server and how your server is responding. Do these other applications not give you a more meaningful error?– MrWhite
Jan 5 at 22:53
The response from
https://aurora.igloo.ooo/manifest.jsoncomes back from "nginx/1.2.1", not Apache?– MrWhite
Jan 7 at 23:01
1
@David Yes - I was really just trying to draw this to the attention of the OP, as they made no reference to this in the question. If nginx is being used as a proxy then it potentially changes the focus of the question.
– MrWhite
Jan 8 at 23:38