arvgta / ajaxify

Ajaxify - An Ajax Plugin
https://4nf.org/
275 stars 124 forks source link

When a page redirects, the new url is not applied to the page #168

Closed tchapi closed 5 years ago

tchapi commented 5 years ago

For instance, if I have a login form at /login that POSTs my credentials to the same page, and then normally redirects to / (the home of my website), then the url will not be updated with / but will only be updated with the previous url, /login.

Is it possible to "follow" the redirect and update the url accordingly ?

Thanks

arvgta commented 5 years ago

If your pages support the canonical attribute, please try setting the Ajaxify parameter:

canonical: true
tchapi commented 5 years ago

Yes I've seen this setting, but it's a little different. The canonical works if for instance I have a page that has two urls, one that is canonical and another. In my case, it's not a canonical redirect, it's a redirect after a login page for instance, so I cannot set any canonical url in the page.

Maybe I'm not clear ? Basically, I think the success function should do something like that (pseudo code of course) :

if (jqXhr.status == REDIRECT) {
     changeUrlTo(jqXhr.headers.location)
}
arvgta commented 5 years ago

Thanks for your sharp thinking again and even supplying the pseudo-code! This issue may seem trivial to you, and testing status for a redirect is probably trivial indeed, but instructing Ajaxify to fetch a different page altogether within the success branch should be done carefully.

There are plenty of existing mechanisms at our disposal, but I have to think about that one a bit...

tchapi commented 5 years ago

In fact, I don't think you actually need to fetch a different page because the HTTP standard works for you :) the ajax request will automatically follow the redirect, and the content that you will get will actually be the content of the final redirected page.

I've tested this and it actually is the case. The only thing is that when you update the url, you take the first url (the one you navigate to) and not the redirected one, which leads to an inconsistency.

So I think (but tell me if you find otherwise) that the only thing you need to do on the ajaxify side is to extract the last headers.location and update the url, no ?

arvgta commented 5 years ago

Very interesting! If you've tested that successfully already, then you could just specify the tested code to enter in the success branch?

Maybe I should introduce a new parameter in the Ajaxify interface like:

redirect: true  //default true

...so the mechanism can be shut off, if any user happens to have problems with it...

tchapi commented 5 years ago

I know it works theoretically but unfortunately you'll have to use a native javascript ajax call, not the jquery one, to gain access to responseURL (see https://github.com/jquery/jquery/pull/4405) (which is the last location after the redirect). See https://stackoverflow.com/a/53714398/1741150 for instance.

Or, you would need to parse the page's to extract the canonical url, if any.

Your parameter would be useless since an ajax call transparently follows the redirects (and you can't prevent it from doing so). The only missing detail is the last url that was redirected to.

arvgta commented 5 years ago

(On a side-note, a bit off topic, but I don't know how to inform you otherwise: I have mentioned you on my Thanks page and would be happy to list your site, that uses Ajaxify on my Demos page, as you have mentioned, that it has a login page etc. and thus is fairly complex. Please let me know, when it goes live... )

I had a look at the jQuery ticket #4405 and the Stackoverflow thread - it seems like "cutting edge" stuff, although the actual desire ought to be common to quite a lot of developers. At the moment, going low-level Javascript in this instance is not an option for me. I love jQuery and how it makes syntax more cryptive and encapsulates funnies across browsers. If I can't provide a parameter to suppress the logic on demand, that's another reason not to go forward with it...

Quite a lot of use-cases have been reported to have been solved by simply specifying:

canonical: true

Thanks nevertheless for the interesting idea!

If you do find a suitable workaround or similar for your site, please do consider sharing it...