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?
Related
I want to 301 redirect the URLs from previous site that are nested, as pencilblue doesn’t support them,
e.g. a/b to page/b
For this I have been experimenting in include/http/request_handler.js but facing some issues.
Call never comes inside RequestHandler.prototype.handleRequest or even RequestHandler.prototype.onSessionRetrieved (seems these methods are not being called from anywhere)
Therefore I placed the code in RequestHandler and after confirming that req is not for public resource or api, I create a new url and execute
return this.doRedirect(newUrl, 301)
This actually works but at the same time I receive
Can’t render headers after they are sent error
#1075 has not helped me much as I’m not sure which specific controller I should modify. I need to catch the req as early as possible and see if it’s a page then redirect to page prefixed url.
Thanks in advance.
There are couple of ways to do redirects. You can do them from a controller or from middleware. You are correct in that, some of the functions in the request handler are not called. These are deprecated despite the fact pencilblue team didn't mark them as such. They replaced a good deal of the request handler functionality with /include/http/router.js and include/http/middleware/index.js. Plugins can register their own middleware to hijack the request pipeline.
See Advanced Routing on wiki for more info about creating your own middleware.
Using the routing framework your plugin would be able to register middleware that would be able to inspect the request and then redirect based on your specific criteria. The Router will be accessible from req.router and from there you could call req.router.redirect (Source).
Reference: #1224
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?
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'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?
I used HttpClient and GetMethod to get the page source of the URL :
http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=Logarithmic&chdeh=0&chdet=1264263288788&chddm=391&chddi=120&chls=Ohlc&q=NSE:.NSEI&
But somehow I always end up getting page source of :
http://www.google.com/finance?q=NSE:.NSEI
Can anyone tell me why and how to get page source of the former URL?
I'm going to go out on a limb here and assume that what's going on is that your HttpClient implementation handles HTTP redirects internally and so when you call GetMethod on the first URL, the server (google.com) is probably sending back an HTTP redirect (302, or 301) response for the second URL which is what you end up getting back.
The reason for that is probably that the first URL requires some sort of cookie which you're not providing when you make your request. The best way to determine exactly what happens when you make the request that way is to use a tool such as WireShark or Fiddler to analyse the HTTP request/response sequence from your HttpClient and that of a normal request made using FireFox or IE and see what exactly is different.