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)

x86
Windows XP
defect
Not set
normal

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?
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.
mike, what about:

4b. URL is version 2 with application version is 1.5? (also, the broken profile problem)
(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.*."
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)
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?
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.
fwiw, upon a 404, the client side will show this in the update ui:

"AUS: Update XML File Not Found (404)"

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.