1) If the mini-manifest returns 3xx redirect, does FxOS follow it? 2) If that redirect is a 301 redirect, should we update the URL on device so update pings hit the new URL instead of the old one? 2 is a way for the developer to migrate to a new URL structure or a new domain and change where the pings go. Without this, if the developer does change the URL updates no longer work. There are likely security concerns here. (e.g. Site A gets hacked, 301s the mini-manifest to site B)

I cannot tell what the bugs are here and what's actionable. Can you clarify?

STR: 1. Have an approved packaged app on marketplace with a few versions 2. Change the app slug from the dev hub 3. Upload another version for the app With our current implementation of updates, changing the app slug would break updates since the mini manifest uses the slug when we ping for updates. We are trying to fix this problem in bug 818120. We are curious to find out if- a) Firefox OS is inherently capable of dealing 3xx redirects in the mini-manifests b) Updating itself if there is a 301 (permanent redirect) c) Security concerns (as outlined in comment 0) and how to mitigate them

Sounds like a Jonas question. Jonas - Thoughts?

To keep things simple for v1, I don't think that we should follow 3xx redirects at all. Any attempt at redirects should simply not be followed. This doesn't match the current behavior. Right now I *believe* we follow redirects, but we don't update the URL. However I'd like to get that fixed, though that likely won't happen in time for v1. In the meantime I'd recommend that the mozilla marketplace doesn't rely on redirects working.

(In reply to Jonas Sicking (:sicking) from comment #4) > To keep things simple for v1, I don't think that we should follow 3xx > redirects at all. Any attempt at redirects should simply not be followed. > > This doesn't match the current behavior. Right now I *believe* we follow > redirects, but we don't update the URL. Correct. > However I'd like to get that fixed, though that likely won't happen in time > for v1. If we can find that we gott redirected in an xhr or at the channel level, this should not be too hard.

Might be worth to discuss this in triage just in case after reading comment 4. I'd like to know if the risks aren't too significant if we leave this bug in (or if the opposite is true).

All the discussion here is about the mini manifest, so lets scope this bug to that. This is a nice-to-have, not a blocker.

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.