Closed
Bug 368578
Opened 17 years ago
Closed 2 years ago
log details about every "unexpected" null <updates> that AUS generates (due to frankenfox or otherwise)
Categories
(AUS Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
4.x (triaged)
People
(Reporter: moco, Assigned: morgamic)
Details
log details about every "unexpected" null <updates> that AUS generates right now, by design, I can hit aus with a URL and get a valid, empty <updates> xml data (<updates> </updates>). In some scenarios, like when you are running the latest release, this is the expected behaviour. And, there are also work arounds on the AUS side for some client issues, to return empty updates XML data for things like: https://aus2.mozilla.org/update/2/Firefox/1.5.0.9/.... (because version 2 should not happen for 1.5.0.9, see bug #360127) But, what about all the other scenarios where http://lxr.mozilla.org/mozilla/source/webtools/aus/xml/index.php generates empty updates? Could we log all url requests that result in unexpected empty <updates> result, in order to help track down potential issues?
Assignee | ||
Comment 1•17 years ago
|
||
Yes, we could expand the error detection and log the URL with a reason. So far there are four cases for no-update: 1. Patch info not found (for explicit channel or fallback channel) 2. Is a nightly and build ID is already latest 3. OS_VERSION is invalid 4. URL is a version 1 with OS_VERSION data (broken profile problem) Will have to look at where to log it. I imagine this log might get fairly large.
Reporter | ||
Comment 2•17 years ago
|
||
mike, what about: 4b. URL is version 2 with application version is 1.5? (also, the broken profile problem)
Assignee | ||
Comment 3•17 years ago
|
||
(In reply to comment #2) > mike, what about: > > 4b. URL is version 2 with application version is 1.5? (also, the broken profile > problem) > Yes, that was basically what I was referring to. That expands it. I guess it's: "URL is version 1 with OS_VERSION data and product version is 1.5.*."
Reporter | ||
Updated•17 years ago
|
Summary: log details about every "unexpected" null <updates> that AUS generates → log details about every "unexpected" null <updates> that AUS generates (due to frankenfox or otherwise)
Reporter | ||
Comment 4•17 years ago
|
||
as it relates to bug #394245, dan points out: <thunder> interestingly enough, if I replace the extra "/" in your example with %2F <thunder> I get an error from aus <thunder> https://aus2.mozilla.org/update/2/Firefox/3.0a8pre/2007082905/WINNT_x86-msvc/en-US/nightly/Windows%2F_NT%205.1/update.xml?force=1 <thunder> possibly aus uses [some of] the fields to look up files on disk? <thunder> and so you get a 404 when the slashes are correctly escaped morgamic, are you seeing a bunch of 404s in the AUS logs?
Assignee | ||
Comment 5•17 years ago
|
||
Looks like it's breaking the apache rewrite somehow: RewriteRule ^update2/(.*)$ index.php?path=$1 [QSA] RewriteRule ^update/(.*)$ index.php?path=$1 [QSA] Will look into 404s and see what causes this 404. Probably something to do with QSA or auto-decoding in PHP for query string args.
Reporter | ||
Comment 6•17 years ago
|
||
fwiw, upon a 404, the client side will show this in the update ui: "AUS: Update XML File Not Found (404)"
Comment 7•2 years ago
|
||
This bug lies at rest in the graveyard.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•