Change the www.youtube.com HTTP test to use m.youtube.com as the host

[aww-aww]

Most mobile user agents will get a 302 to m.youtube.com if you try to fetch www.youtube.com, so the current test fails really often as it is not expecting a 302 response.

[drchoffnes]

Fixed.

[ghost]

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users can
enter their own sites. Ideally, Mobiperf would handle 302s gracefully and,
even better, report them. Many mobile site delays are caused by redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes [email protected]:

Fixed.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/143#issuecomment-10716235.

[drchoffnes]

Correct on the change.

Agreed that mobiperf should handle other response codes more gracefully.

On Nov 26, 2012, at 9:55 AM, Dominic Hamon [email protected] wrote:

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users can
enter their own sites. Ideally, Mobiperf would handle 302s gracefully and,
even better, report them. Many mobile site delays are caused by redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes [email protected]:

Fixed.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10716235>.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/143#issuecomment-10725963.

[mdwelsh]

My understanding is that Mobiperf does NOT follow HTTP redirects and
instead reports whatever response code the server gives us back. This is
important so we can avoid things like redirect loops. Accurately emulating
browser behavior with regards to redirects and things like caching is
challenging here.

On Mon, Nov 26, 2012 at 12:22 PM, drchoffnes [email protected]:

Correct on the change.

Agreed that mobiperf should handle other response codes more gracefully.

On Nov 26, 2012, at 9:55 AM, Dominic Hamon [email protected]
wrote:

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users can
enter their own sites. Ideally, Mobiperf would handle 302s gracefully and,
even better, report them. Many mobile site delays are caused by redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes [email protected]:

Fixed.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10716235>.

—
Reply to this email directly or view it on
GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10725963>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/143#issuecomment-10732104.

[ghost]

It does reduce the usefulness of the HTTP test though: If I go to a site
and wonder why it's taking so long, mobiperf is the perfect tool to start
up and try to run the same test. If I see X redirects before the site
loads, or even X redirects before a timeout of Y seconds (minutes!) then I
might learn a bit more about why that site is so slow. Without this, the
best I learn is that there is at least one redirect.

It might be hard, but I think it's worth considering for a future update.

On Mon, Nov 26, 2012 at 3:32 PM, Matt Welsh [email protected]:

My understanding is that Mobiperf does NOT follow HTTP redirects and
instead reports whatever response code the server gives us back. This is
important so we can avoid things like redirect loops. Accurately emulating
browser behavior with regards to redirects and things like caching is
challenging here.

On Mon, Nov 26, 2012 at 12:22 PM, drchoffnes [email protected]:

Correct on the change.

Agreed that mobiperf should handle other response codes more gracefully.

On Nov 26, 2012, at 9:55 AM, Dominic Hamon [email protected]
wrote:

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users can
enter their own sites. Ideally, Mobiperf would handle 302s gracefully
and,
even better, report them. Many mobile site delays are caused by
redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes [email protected]:

Fixed.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10716235>.

—
Reply to this email directly or view it on
GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10725963>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10732104>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/143#issuecomment-10739497.

[mdwelsh]

I think it depends on what the HTTP test is meant to be used for. We
intended it to be a simple downlink throughput test, not a test of a web
page's loading time.

On Mon, Nov 26, 2012 at 3:35 PM, Dominic Hamon [email protected]:

It does reduce the usefulness of the HTTP test though: If I go to a site
and wonder why it's taking so long, mobiperf is the perfect tool to start
up and try to run the same test. If I see X redirects before the site
loads, or even X redirects before a timeout of Y seconds (minutes!) then I
might learn a bit more about why that site is so slow. Without this, the
best I learn is that there is at least one redirect.

It might be hard, but I think it's worth considering for a future update.

On Mon, Nov 26, 2012 at 3:32 PM, Matt Welsh [email protected]:

My understanding is that Mobiperf does NOT follow HTTP redirects and
instead reports whatever response code the server gives us back. This is
important so we can avoid things like redirect loops. Accurately
emulating
browser behavior with regards to redirects and things like caching is
challenging here.

On Mon, Nov 26, 2012 at 12:22 PM, drchoffnes [email protected]:

Correct on the change.

Agreed that mobiperf should handle other response codes more
gracefully.

On Nov 26, 2012, at 9:55 AM, Dominic Hamon [email protected]
wrote:

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users
can
enter their own sites. Ideally, Mobiperf would handle 302s gracefully
and,
even better, report them. Many mobile site delays are caused by
redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes [email protected]:

Fixed.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10716235>.

—
Reply to this email directly or view it on
GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10725963>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10732104>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10739497>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/143#issuecomment-10739588.

[drchoffnes]

Maybe we should not report it as a failure if it gets a 302. It's not like
the GET failed to reach the web server.

I'm personally more in agreement with Matt, that the http probe should not
follow redirects. I confirmed that we are seeing the 302 status in GAE so
we could eventually use this information to design an experiment that
includes an additional measurement task for the redirect. I'd rather be
explicit about additional GETs than have implicit behavior.

On Mon, Nov 26, 2012 at 5:39 PM, Matt Welsh [email protected]:

I think it depends on what the HTTP test is meant to be used for. We
intended it to be a simple downlink throughput test, not a test of a web
page's loading time.

On Mon, Nov 26, 2012 at 3:35 PM, Dominic Hamon [email protected]:

It does reduce the usefulness of the HTTP test though: If I go to a site
and wonder why it's taking so long, mobiperf is the perfect tool to
start
up and try to run the same test. If I see X redirects before the site
loads, or even X redirects before a timeout of Y seconds (minutes!) then
I
might learn a bit more about why that site is so slow. Without this, the
best I learn is that there is at least one redirect.

It might be hard, but I think it's worth considering for a future
update.

On Mon, Nov 26, 2012 at 3:32 PM, Matt Welsh [email protected]:

My understanding is that Mobiperf does NOT follow HTTP redirects and
instead reports whatever response code the server gives us back. This
is
important so we can avoid things like redirect loops. Accurately
emulating
browser behavior with regards to redirects and things like caching is
challenging here.

On Mon, Nov 26, 2012 at 12:22 PM, drchoffnes [email protected]:

Correct on the change.

Agreed that mobiperf should handle other response codes more
gracefully.

On Nov 26, 2012, at 9:55 AM, Dominic Hamon [email protected]

wrote:

Fixed as in you changed the scheduler to not send to www.youtube.com?

That's not really fixed as youtube is not the only culprit and users
can
enter their own sites. Ideally, Mobiperf would handle 302s
gracefully
and,
even better, report them. Many mobile site delays are caused by
redirects
and enumerating them for users would be very helpful.

On Mon, Nov 26, 2012 at 6:00 AM, drchoffnes <
[email protected]>wrote:

Fixed.

—
Reply to this email directly or view it on GitHub<

https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10716235>.

—
Reply to this email directly or view it on
GitHub<

https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10725963>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10732104>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10739497>.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/143#issuecomment-10739588>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/143#issuecomment-10739702.

[aww-aww]

It would be nice to cover both scenarios. Keep the vanilla HTTP test that does not follow redirects, but modify it so it does not treat a 302 as a failure (it is also worth considering how to handle 204, 301 and 304 responses, as there are valid 'success' cases that may return those codes). A new HTTP test that follows redirects with a max of say 5 redirects to avoid loops would provide additional valuable information.

[aww-aww]

While this is being sorted out, it probably makes sense to remove the HTTP test for www.google.com, as it will fail for most non-US users due to geo detection and a 302 to the localized version of Google.