Code review comment for lp:~dooferlad/linaro-android-frontend/proxy_lava-job-info

On 9 January 2012 22:24, Michael Hudson-Doyle
<email address hidden> wrote:
> I don't understand all the new_style_url/old_style_url gyrations.  In
> particular, it sure looks as if both could go via the proxy, in which
> case both will succeed at the http level (/api/get-lava-job-info always
> returns http 200) and then its a race as to which response gets displayed.

I did have both go via the proxy at one point, but it does leave the
proxy open to anyone wanting to proxy a file that they can call
lava-job-info. It seemed like restricting the domain to be proxied to
snapshots.linaro.org was reasonable.

I have got rid of the code that makes old_style_url always absolute,
since it has gone back to a non-proxied Y.io call.

The reason for there being two URLs and there being no protection
about which gets loaded is that old_style_url will only match jobs
that have jenkins native archiving enabled and my understanding is
that those jobs will be going away shortly and don't account for any
jobs with artefacts published to snapshots.linaro.org.

It is simple enough to stop receivedLavaJobInfo from modifying the
page twice if you think it is worth protecting against. I have checked
in this change to do so:

    function receivedLavaJobInfo (e, response) {
        if (response.response.match(/^Server error: 404$/))
        {
            return; // Nothing to parse
        }

        if (typeof receivedLavaJobInfo.got_info != "undefined")
        {
            alert("Two resutls files found. Please report this error
by submitting a bug report against" +
                  "
https://code.launchpad.net/~linaro-infrastructure/linaro-android-frontend/trunk")
            return;
        }

        receivedLavaJobInfo.got_info = true;

I don't think there is a right location to get lava-job-info from if
it is in more than one location, so this should be sufficient. I added
an alert because it would be nice to know if getting two files ever
happens.

--
James Tunnicliffe