You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Server side X-Up-Target not working for redirects #213
Unpoly seems to ignore the X-Up-Target-Header if it is sent with a redirect response. Probably response headers are only consumed for the destination of the redirect?
Expected behavior
When the X-Up-Target-Header is sent with a redirect response it should be used for the destination fragment updates.
Browser version
OS: Windows
Browser Chromium
Version 91.0.4472.124
Unpoly 2.0.1
Additional context
Unpoly correctly sends the original X-Up-Target-Header for the redirect and the following request. I think that the same behaviour would be consistent for the response behaviour.
This needs to be implemented on the server. It is technically impossible for browser JavaScript to see the headers of a redirecting response ("response 1" above). Redirects are followed automatically, JavaScript only ever sees the final response.
While fetch() has a { redirect: 'manual' } option that allows JS to not follow redirects, it does not allow access to the headers of a redirecting response.
I saw that you're maintaining the django-unpoly integration. The unpoly-rails gem actually persists X-Up headers over redirects. If you would like to do something similar, here's how I did it:
For Unpoly requests, override Rails' redirect_to method to append all X-Up request/response headers as query parameters to the destination URL
When the user asks for e.g. an X-Up-Target header we look either in the query parameters or in the request headers.
Send an X-Up-Location header without these query parameters so they don't ever appear in the browser's location bar
Activity
[-]X-Up-Target not working for redirects[/-][+]Server side X-Up-Target not working for redirects[/+]triskweline commentedon Jul 7, 2021
In your example:
/foo/bar(response 1)/barIs the
X-Up-Target headersent with response 1 or response 2?jwaschkau commentedon Jul 7, 2021
Hey Henning,
the X-Up-Target header is sent with response 1.
I also tried to send the header with response 2, which alters the target fragment on the client side as expected.
triskweline commentedon Jul 8, 2021
This needs to be implemented on the server. It is technically impossible for browser JavaScript to see the headers of a redirecting response ("response 1" above). Redirects are followed automatically, JavaScript only ever sees the final response.
While
fetch()has a{ redirect: 'manual' }option that allows JS to not follow redirects, it does not allow access to the headers of a redirecting response.I saw that you're maintaining the django-unpoly integration. The unpoly-rails gem actually persists
X-Upheaders over redirects. If you would like to do something similar, here's how I did it:redirect_tomethod to append allX-Uprequest/response headers as query parameters to the destination URLX-Up-Targetheader we look either in the query parameters or in the request headers.X-Up-Locationheader without these query parameters so they don't ever appear in the browser's location barRelevant sections in the Ruby code and tests:
unpoly/lib/unpoly/rails/controller.rb
Line 35 in e555c48
unpoly/spec_app/spec/gem/unpoly/rails/controller_spec.rb
Line 960 in e555c48
Closing this issue since there's nothing we can do in Unpoly itself.
jwaschkau commentedon Jul 8, 2021
Hey Henning,
thanks for your helpful answer. I will have a look at the redirect implementation of the Ruby-Integration and add it to the django-unpoly library.