changePage does not honor a 303 redirection

[alangrafu]

When a link http://example.org/a returns an HTTP code 303 (See Other) to http://example.org/b, JQuery mobile changePage changes the URL in the bar to the former where it should be the latter.

[jblas]

jQuery Mobile uses the browser's XmlHttpRequest object to pull in external pages. When the browser recieves a 301, 302, or 303 HTTP status code, it handles it transparently, which means at the jQuery Mobile level, we never see the status for the redirect, we only see the final status 200, or one of the 400 family status codes for the file that was finally loaded.

[jostster]

@jblas This needs to be addressed. There are a few work arounds out there that can be implemented such as providing a status code of 280 so that xmlhttprequest doesn't ignore it. This is a major issue for people that use jqm with another backend language such as PHP to store their sessions. IF the session is expired when someone tries to make a call we need to redirect to the login page. However the URL is that of the page they tried to visit which screws up the login page.

Let's try and find an alternative instead of just saying it cannot be done.

[jblas]

@jostster

I'll reopen so we can re-evaluate our AJAX usage.

[toddparker]

@gseguin - reassigning this to you but feel free to bump from the 1.1 milestone if this requires a fair amount of work/discussion.

[johnbender]

I'm under the impression that this will take a fair amount of work to accommodate, I think we should bump to 1.2.

[toddparker]

@johnbender - moved to 1.2

[toddparker]

Now 1.3

[toddparker]

@johnbender - is this in you plan for 1.3's nav work or should we mov out again?

[gabrielschulhof]

@johnbender In order to handle this at all, we'd have to make the creation of the history entry the last step in the navigation process.

This runs counter to what we were discussing earlier: namely that /everything/ should be handled in response to a hashchange event.

[gabrielschulhof]

@jostster Can you please give an example of how you return a HTTP status of 280?

I've tried to return a 280 with PHP like this:

<?php
    header("HTTP/1.1 280 Custom");
    header( "Location: http://localhost/nix/jqm/jquery-mobile/redirect-target.html" );
?>

... but when I get the response, it's 302, which is normal when including the "Location" header. Do I have to give Apache special instructions to actually issue a status of 280? BTW: I haven't seen this status code documented anywhere.

[gabrielschulhof]

SO offers some advice on this topic.

[gabrielschulhof]

Closing this as a feature request and adding the request itself to the feature request wiki.

I am also trying to come up with a demo of a fix for this issue which can be implemented entirely outside jQuery Mobile. The basic idea is that if one can have the server place some information in the XmlHttpRequest informing the client that this is a redirect (see my previous comment about where such mechanisms are described), then one can gain access to this information during a "pageload" handler, because "pageload" handlers receive the xhr as part of the callback data. If the xhr is identified as having incurred a redirect, then the "pageload" handler can hook up a one-time "pagebeforechange" handler to the loaded document, which receives a modifiable data object as its second argument. One of the data items is the URL to place into the URL's hash (and thus into the location, if pushState is enabled).

[gabrielschulhof]

Digging further into this, I don't believe redirection can be done such that the browser handles it. That is jQM does not have a means by which to become aware of the normal 302/303 redirection. However, if the server answers 200 where it would redirect, and offers the redirect target URL as a custom header, then the custom header can be picked up during the "pageload" event from the callback data object's xhr member via its getResponseHeader() function.

Then, the "pageload" handler can intercept the pagebeforechange event that results from having loaded the page, and overwrite the toPage property of its callback data object. This will cause the navigation to load the redirect target specified in the custom header.