May be this is an awkward question due to my lack of knowledge and I don't know which topic I should search to know about this, but I kind of hope/wish there was a solution.
What I mean is there any way I could send http requests to multiple domains ?
For eg: If I send an http request for a page www.facebook.com/stackoverflow.
I want a simple info that this link is clicked by someone by sending a message to my domain also.The URL can be changed to anything with primary URL still as main source.
What I mean plainly is
www.facebook.com/stackoverflow+{additional code to some way a request to my website also }
When you send a request for http://www.facebook.com/stackoverflow, it requires making a TCP connection to www.facebook.com's server and then sending an HTTP request for the /stackoverflow resource on that server. You can't make Facebook forward the same request to another server.
If you want the link to request your domain, you have to declare your domain as the target of the link. You can specify another URL as an extra parameter, so your domain can use an HTTP redirect to forward the client to that URL when ready. For instance, search engines do this all the time to track the links that users click on in search results.
For example:
http://www.example.com/doSomething?goto=http%3A%2F%2Fwww.facebook.com%2Fstackoverflow
The client would connect to the www.example.com server and send a request for /doSomething?goto=http%3A%2F%2Fwww.facebook.com%2Fstackoverflow. A script located at /doSomething can do whatever it needs to do, and then redirect the client to the URL in the goto parameter (http://www.facebook.com/stackoverflow).
Related
Background
I was making a browser extension that sends a POST request to http://ip.v4.ad.dr/somephp.php which does some data handling based on the POSTed data. This extension is supposed to function on the site https://meet.google.com/.
Problem
My problem arises because I am sending from https to http, so my request is blocked and this error appears:
Mixed Content: The page at 'https://meet.google.com/mym-eets-url?authuser=x' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://ip.v4.ad.dr/somephp.php'. This request has been blocked; the content must be served over HTTPS.
Please note that those are fake URLs. They are just there to signify that this is what the URL looks like, not what it is. mym-eets-url is My Meet's URL, and ip.v4.ad.dr is IPv4 Address
Attempts to solve
I have thought of:
Making/using some site that reflects the request to the target URL. I do not think this works since that mirror site may block the request, since it is https.
Making my localhost use https. I am pretty sure this will work, but I don't want to use https simply because the request won't send otherwise. I can try doing this if there isn't any other option.
Question
What is the best way to send a request from a https site to my own http://ip.v4.ad.dr/ server?
I have looked through many sites but I have yet to find the answer to this question:
I have a login page and after the user logs in I want to redirect to a completely different URL. But while redirecting it I want to pass the username with the http request. So for example:
request.setHeader(“test”,“testing.request) and then from the server side they can retrieve the header by request.getHeader(“test”).
I assume that with "redirect" you mean doing response.sendRedirect(newURL);. That means, that your login servlet, after a successful login, tells the browser, that it should send new request. The new request uses GET method, so the only way to add parameters is to add them directly to the new URL, e.g. response.sendRedirect("http://your.server/new/location?username=johndoe");.
If you want to use and modify the original request, I would suggest you to read http://www.javapractices.com/topic/TopicAction.do?Id=181 (Forward versus redirect).
I'm starting to learn web-programming. I've read about the difference between forward and redirect. But two questions not fully understood still:
In which case does the process access to a server-side and in which case without server-side?
When does URL change and when doesn't change? Does URL changes always when redirecting? Does URL changes never when forwarding?
I would be very grateful for the clear answers and explanations! Thanks in advance!
They are not hard and fast terms.
A redirect usually means an HTTP redirect, which is an HTTP response that instructs the client to make a new HTTP request to a different URI.
An internal redirect is a common description of a redirect that is handled internally by the webserver / web application / etc and doesn't send the browser to a different URI.
Forward is not a particularly common term, but when I've encountered it it usually means a form of internal redirect.
Forward happens on serverside, server forwards the same request to another resource. whereas redirect happens on the browser side, server sends http status code 302 to browser so browser makes new request.
Redirect requires one more round trip from browser to server.
One more difference is redirect reflects in browser address bar forward doesnt.
Is there any way to recognize (by process http packet or filtering tcp connections) does several requests belong to one opening url or another?
Try to explain in more detail.
When we open any page in browser it also initializes different requests to download images, resources, scripts. I d like to get know that some scope of requests was invoked by opening site (call it main site).
I can get referer property but in that case how to distinguish request to resorce from request to different site link on which was clicked on main site. In both cases referer will be the same.
I suspect that this problem could not be resolved, but I hope that I'm mistaken. Or you can offer some workaround.
If you are in control of the site, set a cookie or a URL parameter and check if it exists in subsequent requests.
Some parts of my website are only accessible via HTTPS (not whole website - security vs performance compromise) and that HTTPS is enforced with a 302 redirect on requests to the secure part if they are sent over plain HTTP.
The problem is for all major browsers if you do a 302 redirect on POST it will be automatically switched to GET (afaik this should only happen on 303, but nobody seems to care). Additional issue is that all POST data is lost.
So what are my options here other than accepting POSTs to secure site over HTTP and redirecting afterwards or changing loads of code to make sure all posts to secure part of website go over HTTPS from the beginning?
You are right, this is the only reliable way. The POST request should go over https connection from the very beginning. Moreover, It is recommended that the form, that leads to such POST is also loaded over https. Usually the first form after that you have the https connection is a login form. All browsers applying different security restrictions to the pages loaded over http and over https. So, this lowers the risk to execute some malicious script in context that own some sensible data.
I think that's what 307 is for. RFC2616 does say:
If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
but it says the same thing about 302 and we know what happens there.
Unfortunately, you have a bigger problem than browsers not dealing with response codes the way the RFC's say, and that has to do with how HTTP works. Simplified, the process looks like this:
The browser sends the request
The browser indicates it has sent the entire request
The server sends the response
Presumably your users are sending some sensitive information in their post and this is why you want them to use encryption. However, if you send a redirect response (step 3) to the user's unencrypted POST (step 1), the user has already sent all of the sensitive information out unencrypted.
It could be that you don't consider the information the user sends that sensitive, and only consider the response that you send to be sensitive. However, this turns out not to make sense. Sensitive information should be available only to certain individuals, and the information used to authenticate the user is necessarily part of the request, which means your response is now available to anyone. So, if the response is sensitive, the request is sensitive as well.
It seems that you are going to want to change lots of code to make sure all secure posts use HTTPS (you probably should have written them that way in the first place). You might also want to reconsider your decision to only host some of your website on HTTPS. Are you sure your infrastructure can't handle using all HTTPS connections? I suspect that it can. If not, it's probably time for an upgrade.