301 redirection doesn't update browser url

[lucasflorian]

Hi,

Using version 2.9.7

When receiving a 301 HTTP code from the server, the next page has the right content, but the browser URL is the requested url, not the response location header

I have a link that leads to :

https://domain.com/url

Server response is a HTTP 301 with location header :

https://domain.com/url/suburl

The content displayed by barba is the one from https://domain.com/url/suburl but the browser url is still https://domain.com/url

Thanks

[xavierfoucrier]

Hi @lucasflorian,

Interesting case: I will look into it soonly. Thanks for the issue :wink:

[xavierfoucrier]

Hi @lucasflorian,

I can confirmed it's a bug, mostly an unsupported feature I mean :smile: !

Page is well prefetched/displayed, even with prefetchIgnore: true, but URL is not properly refreshed in the browser with the 301 targeted page URL...

For now, you can manually update the history in your code using:

barba.history.add('sub/suburl/');

See History class API for more informations.

[arun07as]

I've had the same issue ( just that in my case its a 302 as the page is only accessible to authenticated users ).

Is there any way I can get the response status code and the location header inside the barba hooks (or from anywhere else) so that I can check if there is a redirect, and then change the url to the Location header using the history api?

[xavierfoucrier]

@arun07as see https://barba.js.org/docs/advanced/recipes/#Browser-requests :wink:

[johnrobertcobbold]

@arun07as see https://barba.js.org/docs/advanced/recipes/#Browser-requests 😉

Hello Xavier,

I presume that you are referring to requestError in that link? We are having the same problem as @arun07as: some of our pages trigger a 302 redirect. Barba follows the redirect but does not update the url which is a problem for us.

On pages which require authentification, we have started returning a 401 error instead of a 302 redirection. This gets picked up by requestError so we can access the url that the user was trying to open, and forward some_parameters to a 401 page using something like barba.go('/401?some_parameters'). This is perfect because our 401 page can then use those parameters to redirect the user back to the original page upon sign-in. If we were not able to update the URL, this would not work.

On some other pages, we have genuine innocent 302 redirects and returning an 4xx does not make sense. For those pages, requestError does not trigger so we are stuck and cannot update the url. This is a problem as the user sometimes ends up with a url which is not valid. Would the only way around this is to be able to access the status code, even when there was no error?

[xavierfoucrier]

Hi @goyavo,

Probably accessing the code will help developers deal with this kind of issue. @thierrymichel has self-assigned and will fix this in a next release.

We are all a little busy right now, sorry for the delay. Thanks for your patience :wink:

[vkzawa]

Thought I'd dig in on this and see if I could throw something together quickly but it looks like this would require a much bigger restructuring of the code to support 301/302 redirects than I expected.

I'll write up an outline of what I think needs to be done then maybe either @xavierfoucrier or @thierrymichel could review it. If neither of you have started work by the time I'm ready to add this feature for our own projects this then I'll get started on a pull request for this.

I maintain a custom Express framework with which my team and I are building many sites (we've got 19 done and 30 or so lined up.) While I'd love to build our sites on something newer like Gatsby or Next.js that would be a huge migration for us, so Barba is a perfect solution for now to get a more modern single-page-app experience. We've already launched one site with Barba and we're looking to bake it into all future sites.

[fredy31]

Any update on this? Working with Barba on a WP install I'm stuck if my 301's don't update the URL.

[fredy31]

If others fall on that problem, here is a (very) dirty fix. I put the supposed page URL in the code, and check if both URLs match before showing the page. If the supposed URL is not the same as the JS readable URL (I've put that it only checks the last chunk, it should do) force a redirect of the page.

barba.init({
  transitions: [
    {
      name: "default-transition",
      leave(data) {
        return gsap.to(data.current.container, {
          opacity: 0,
        });
      },
      enter(data) {
        var supposedURL = jQuery(data.next.container).find('.js-variables-mule').attr('data-url');
        supposedURL = stripTrailingSlash(supposedURL).split('/');
        supposedURL = supposedURL[supposedURL.length - 1];
        var currURL = window.location + '';
        var currURLNoHash = currURL.split('#');
        currURLNoHash = currURLNoHash[0];
        currURLNoHash = stripTrailingSlash(currURLNoHash).split('/');
        currURLNoHash = currURLNoHash[currURLNoHash.length - 1];
        console.log(supposedURL +' '+ currURLNoHash);
        if(supposedURL != currURLNoHash){
          console.log('redirect');
          jQuery('#swup').css('display','none');
          jQuery('body,#swup').css('display','none');
          jQuery('body,#swup').css('opacity','0');
          window.location.href=currURL;
          return;
        }
        return gsap.to(data.next.container, {
          opacity: 1,
        });
      },
    },
  ],
})

function stripTrailingSlash(str) {
  if(str.substr(-1) === '/') {
      return str.substr(0, str.length - 1);
  }
  return str;
}

Like I said: its a VERY dirty fix, but it does work for now. It is also slower, because the page has to load first, check if its allright, and if it isn't do the reload.

[andersdn11]

Any progress on this? Still causing issues for me.

[xavierfoucrier]

Hi everyone, unfortunately not. We will work on barbajs on October/November now.

Thanks again for your patience.

[SamJol]

Any update on this? I'm having the same issue :(

[daun]

Both XMLHttpRequest and fetch support getting the final url after all redirects. See XMLHttpRequest.responseURL or Response.url. That could be used to update the current url and any cache entries. Especially for temporary 302 redirects, it'd be important not to cache the requested page but the final url.

I've tried monkeypatching barba's request helper, but haven't found an easy way to update all the places the href would need to be updated after the page has loaded and the final URL is known.

[xavierfoucrier]

Hi everyone 👋 Quick update: I will work on this in the next few days.