In a React-based application with server-side rendering, I am using the match utility of React Router. To redirect from some urls to others, I use React Router's Redirect component. On the server side, I am checking the redirect parameter of the callback function that match takes (which is the Location object), and if this parameter is present (as it is when the Redirect component is matched), I use it for redirecting, like so:
if (redirect) {
let { pathname, search } = redirect;
res.redirect(301, `${pathname}${search}`);
}
Here is the problem. In the code snippet above, my server will always redirect with http code 301, while I need to send 302 responses in some cases, and 301's in others. I can't figure out a good, idiomatic way to pass an extra piece of information through React Router, which the server can then use to decide between a 301 or a 302 redirect. Could you please offer any suggestions?
Related
When a client browser receives a 302 response, does the browser modify or ignore any parameters appended to the end of the URL?
For example, I have a server that redirects requests to a different URL but retains any parameters from the original URL and appends to the end of the new redirect URL. However, browser is not including the parameters in the new URL.
For example, if a request comes in to "https://server1.com/path1?filter=value", the redirect server responds with a 302 and "location: https://server2.com/path2?filter=value". But, issue is that the client browser seems to only recognize "https://server2.com/path2".
Should parameter values be tagged a different way in the response?
As noted by Remy Lebeau in the comments to the question, the browser does not modify the location URL in the 302 response. Rather, the issue was caused by the networking in AWS - I was using AWS Lambda to perform the re-direct by reading in the URL on the original request coming in and re-directing according to mapping in the function. First issue was that API gateway was stripping off the query parameters before it was hitting the Lambda function. Second issue was that the function read the "rawPath" attribute from the request, but this does not contain URL query parameters; the query parameters are contained in the "rawQueryString" attribute instead.
I am trying to implement "redirect handler/filter" on JAX-RS(Jersey) client side. The expectation is that this handler would get invoked before actual redirection by Jersey takes place.
So far I could find is to disable follow redirect and implement own redirect filter, but this means I have to implement full redirect handling including handling loops or other edge cases, which I am trying to avoid and want to rely on Jersey implementation.
I only want to add/change header or other parameters inside the request before actual redirection takes place. Also there are only few redirect we want to manipulate while let other redirections work as is.
Disabling redirect:
ClientBuilder
.newBuilder()
.withConfig(new ClientConfig(clientConfig))
.property(ClientProperties.FOLLOW_REDIRECTS, false)
.build();
Sample redirect handler:
Response resp = requestContext.getClient().target(responseContext.getLocation()).request()
.method(requestContext.getMethod());
responseContext.setEntityStream((InputStream) resp.getEntity());
responseContext.setStatusInfo(resp.getStatusInfo());
responseContext.setStatus(resp.getStatus());
Are there any pointers or reference I can use to intercept redirect?
I am trying to get the redirect response location fragment of a fetch API request. But I can't figure how to access it, if possible.
The context is that I am doing an OpenID Connect request in implicit flow, for a WebRTC Identity Proxy assertion generation.
OIDC specs define the answer of the request as:
When using the Implicit Flow, all response parameters are added to the
fragment component of the Redirection URI
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
...
So I'm making the request with fetch set in manual mode. But the response is then an opaque-redirect filtered response, which hides the location header. (https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect)
Other mode for fetch are error and follow which would not help. While XHR automatically follows the redirect so would not help either. I may be missing something from the fetch API, but it seems to be something hidden on purpose.
Could someone gives me a way to access this information (or a confirmation it's impossible) ?
Is there any alternative to fetch and XHR to make this request, which would allow to access the redirect location header?
Since XHR automatically / opaquely follows redirects (in the event you're using the whatwg-fetch polyfill for example), one possible solution is to check the response.url of the fetch resolution, to see if it matches a redirect location that you expect.
This only helps if the possible redirect locations are limited or match some pattern --- for instance, if you could expect at any time to be redirect to /login:
function fetchMiddleware(response) {
const a = document.createElement('a');
a.href = response.url;
if (a.pathname === '/login') {
// ...
} else {
return response;
}
}
fetch(`/api`)
.then(fetchMiddleware)
.then(function (response) {
// ...
});
fetch isn't able to polyfill the entire standard. Some notable differences include:
Inability to set the redirect mode.
See David Graham comment on the Disable follow redirect:
This is a nice addition to the Fetch API, but we won't be able to polyfill it with XMLHttpRequest. The browser navigates all redirects before returning a result, so there is no opportunity to interrupt the redirect flow.
My Solution:
1). First solution: we are sending 200 status and redirect url(in the http header) from the server and client is redirecting based on that.
2). Second solution: Server could also redirect to with 301 and redirect url. I think, This is the best solution(i.e if we consider SEO).
I have an ASP.NET website. A user can access the URL /partners/{partner-id} in my app. When that url is invoked, I do two things:
1) I want to log the partner ID and user that requested it and
2) Redirect the url to the partner's website.
My question is, which HTTP Status Code should I use? I was using 301. However, that introduced a problem where my logging code was getting skipped. I suspect its because a 301 represents a permanent redirect. However, I basically want to remain the middle man so that I properly log the details.
What HTTP status code should I use?
Thanks!
Taking a look here:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
you should use the 302 status code. Two useful points about the 302 redirect:
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests
This says by inferring that the redirect may be temporary, clients should always check the initial URI instead of going to the redirect URI as a default behavior, meaning they will pass through your logging system each time rather than going directly to the redirected URI on subsequent requests. The 302 response also states:
This response is only cacheable if indicated by a Cache-Control or
Expires header field.
By default, the 301 redirect is cacheable unless you explicitly specify, but the 302 is not cacheable unless explicitly specified.
However, it's probably a good idea to explicitly add in 'do not cache' headers to the redirect to let the client know that it should not be cached just in case you have a client that doesn't follow the default spec behavior. There are a number of other answers in stackoverflow regarding this, here's a decent one:
How to control web page caching, across all browsers?
I'm asking this one for the record:
So I have a client making an Ajax call and I'm trying to have the server handle it and redirect the client server-side.
The express docs make it seem res.redirect(path) is going to actually send a response from the server for the client to redirect(re-route).
e.g.
var path = 'http://localhost:8080/newRoute';
res.redirect(path);
//the client will now go to http://localhost:8080/newRoute
But it appears that this only tells the client to make another request to
the url given.(Which seems useless, but that is what my network requests are showing currently).
Many suggest to do the following to do an actual redirect server-side
var path = 'http://localhost:8080/newRoute';
response.writeHead(302, {'Location': path});
response.end();
So does this mean that that we need to change the header in order for the redirect work?
i.e.
res.location('http://localhost:8080/newRoute');
res.redirect('http://localhost:8080/newRoute');
But the above looks horribly redundant and makes res.redirect look like it wasn't intended for server-side redirects to a new page.
Yet the Express docs show an example like this:
res.redirect('http://google.com');
which I don't know how that could be interpreted any other way than "send the client to the page 'http://google.com' ".
Big Question:
So is res.redirect(path) suppose to handle server-side redirects? If not, what do we do?