825218 - We should be more helpful in case of the archive doesn't have an ETag and fail if the manifest does not have an etag

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Julien Wajsberg [:julienw]]

Per bug 824695 comment 19, we should do a HEAD request before the GETting the archive for packaged apps, to check for the existence of the ETag header.

If the ETag header is not present, we should trigger a download error.

Jonas, please explain why you think this should block v1.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think that this blocks, but I do think it's a somewhat important bug.

Not fixing this means that if the server changes the contents of the minimanifest, but the contents of the application doesn't change, that the user would get notified about a new version being available.

I.e. as things stand now, if the application server were to update the minimanifest to include some additional information, the user would be updated about a new app version being available. When the user choose to apply the download, the download would be instant without any data actually being downloaded.

This is both bothersome and confusing to the user, but otherwise doesn't cause any harm.

Comment 3

[Julien Wajsberg [:julienw]]

In Bug 824695 we check for the existence of an ETag as soon as we get the headers from the GET request.

Therefore, I rewrite this bug title to make it more accurate.

Comment 4

[Julien Wajsberg [:julienw]]

We need to do something if manifest does not have etag either.

Comment 5

[[:fabrice] Fabrice Desré]

Isn't this a WONTFIX now that we have support for hashes both for manifests and packages from bug 829934 ?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #5)
> Isn't this a WONTFIX now that we have support for hashes both for manifests
> and packages from bug 829934 ?

I think so. Testing this so far has revealed that the hash support has really made this robust now. If it happens that we discover that more checking is needed, then we can revisit this at some point in the future.

Comment 7

[Julien Wajsberg [:julienw]]

Except we still check for an ETag header on the package and fail early if it has not this header.

see http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2039

I suggest bugmorphing this bug to remove this check, or do a followup to bug 829934.

Comment 8

[Julien Wajsberg [:julienw]]

Found that you're handling this in fix for Bug 832408 so ok.