For example, when you navigate to http://foo.com/foo.pak?user=moz!//index.html [1] will not consider this format of URL a packaged web content. Instead, it will start downloading "http://foo.com/foo.pak".

[1] https://hg.mozilla.org/mozilla-central/file/a955ea9382af/netwerk/protocol/http/nsHttpChannel.cpp#l5013

Hi Valentin, Jonas, Could we have your input regarding this issue? IMO, http://foo.com/foo.pak?user=moz!//index.html should work as http://foo.com/foo.pak!//index.html except the server would respond http://foo.com/foo.pak based on query string "?user=moz". However, for http://foo.com/foo.pak!//index.html?user=moz I have no idea what kind of request we should send to the server (http://foo.com/foo.pak or http://foo.com/foo.pak?user=moz)

I dealt with the first half of this question in bug 1172697 (based on an IRC conversation with Jonas, from what I recall) Meaning if the "token" is in the URL query, we do not treat this as packaged app. For the second case we just fetch the package and look for a resource named index.html?user=moz The thinking was that a user could use other request headers to specify which package the server should send. Of course, this is fairly arbitrary, and we could change it at any time if we feel we should.

I don't have a strong opinion about what we should do in either case here. Definitely something that I don't think is a high priority to solve. I'd rather do nothing until we have more author feedback. My gut guess is that it might be good to let "http://foo.com/foo.pak!//index.html?user=moz" simply load "index.html" from the page, and let page JS act on any query parameters. However, that's a pure guess. So better wait for author feedback I think.

The web packaged apps implementation was removed from the tree.