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/126.96.36.199/.... (because version 2 should not happen for 188.8.131.52, 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.*."
11 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)
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)"
You need to log in before you can comment on or make changes to this bug.