Closed Bug 825218 Opened 11 years ago Closed 11 years ago
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
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.
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.
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.
Summary: We should check for ETag before downloading the archive → We should be more helpful in case of the archive doesn't have an ETag
We need to do something if manifest does not have etag either.
Summary: We should be more helpful in case of the archive doesn't have an ETag → 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
Isn't this a WONTFIX now that we have support for hashes both for manifests and packages from bug 829934 ?
(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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
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.
Found that you're handling this in fix for Bug 832408 so ok.
You need to log in before you can comment on or make changes to this bug.