I want to know whether 301 redirect always preserve referrer.
I make a page called "gotoorig_https.html" which contains a hyperlink to a page "orig_https.asp".
"orig_https.asp" will 301 redirect to "dest.html" which shows the document.referrer.
In this case,
http page(gotoorig_https.html) -> orig_https.asp(301 redirect)-> https page (dest.html) <--the referrer preserves
https page(gotoorig_https.html) -> orig_https.asp(301 redirect)-> https page (dest.html) <--the referrer preserves
I also make a page called "gotoorig_http.html" which contains a hyperlink to a page "orig_http.asp".
"orig_http.asp" will 301 redirect to "dest.html" which shows the document.referrer.
In this case,
http page(gotoorig_http.html) -> orig_http.asp(301 redirect)-> http page (dest.html) <--the referrer preserves
https page(gotoorig_http.html) -> orig_http.asp(301 redirect)-> http page (dest.html) <--the referrer DOES NOT preserve.
Why does the last case happen?
RFC doesn't specify any referrer-specific behavior in status 301 definition, nor 301-specific behavior in Referer header definition. Thus, I have to say that although this referrer-preserving behavior is logical, it is not defined in RFC and thus you can never be sure.
When going between HTTP and HTTPS the HTTP spec says that a referer header should NOT be sent (see 15.1.3 in RFC2616). The spec doesn't say what should happen between HTTPS pages however.
Interestingly firefox defaults to ignoring the spec in this case, but can be made to conform by setting the network.http.sendSecureXSiteReferrer configuration setting.
Over https the browsers are not sending REFERRERS. This is in the RFC.
Related
I had to make redirects for urls with slash to non-slash urls.
I did it with the rule:
rewrite ^/(.*)/$ /$1 permanent;
But as I see this rule does NOT include the redirect for homepage:
https://example.com/ -> https://example.com
How can I also handle the redirect for homepage?
As far as my knowledge goes this cannot be done. When you request http://example.com or http://example.com/ then browser will always sent request to http://example.com/. The server will always see that a / was appended and you can't redirect to a blank URI and remove that /
As you can see in above image I didn't add / on the request url but / was still sent. Read the below question as well
https://webmasters.stackexchange.com/questions/35643/is-trailing-slash-automagically-added-on-click-of-home-page-url-in-browser/35646
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 testing clickjacking mitigation with a simple page like this on another domain:
<iframe src="https://my.domain/login"></iframe>
My login page sends the following headers:
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
Location: https://my.domain/landing
...
I'm surprised to see both IE 10 and Chrome 33 follow the redirect and display my landing page inside the <iframe>. My landing page does not send X-Frame-Options, but I expected the first X-Frame-Options on the login page to trump the redirect. How can I prevent browsers from following the redirect when my login page is displayed in a frame?
I should add that things work as expected (<iframe> is empty/blocked) if the login page doesn't send an HTTP redirect.
From the terminology used in RFC 7034, I conclude that browsers will not apply X-Frame-Options restrictions for HTTP redirects (status codes 301, 302, etc), but rather for any response where the browser processes the content, e.g.:
The use of "X-Frame-Options" allows a web page from host B to
declare that its content (for example, a button, links, text, etc.)
must not be displayed in a frame (<frame> or <iframe>) of another
page (e.g., from host A). This is done by a policy declared in the
HTTP header and enforced by browser implementations as documented
here.
or:
The X-Frame-Options HTTP header field indicates a policy that
specifies whether the browser should render the transmitted resource
within a <frame> or an <iframe>. Servers can declare this policy in
the header of their HTTP responses to prevent clickjacking attacks,
which ensures that their content is not embedded into other pages or
frames.
As an alternative for the login page you could return a HTTP status code 200 and a meta-tag or javascript for redirection, the X-Frame-Option will then apply, but I admit that it's ugly.
From this page on the blog of Matt Cutts, he says that rel=canonical should be a secondary choice if you can't use a 301 redirect. Is there any performance issue with using a 301 redirect instead of a rel=canonical?
In my experience, the performance difference is negligible. There are more steps involved in the implementation of 301 redirects, so rel=canonical might perform slightly better. The extra steps are typically executed very quickly and should not add any noticeable delay or strain on server resources.
rel=canonical
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server builds a page that includes the canonical tag and sends it to the user
301 Redirect
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server issues a 301 redirect to the canonical URL.
User's browser automatically makes a second request for /canonical.html
Server discovers that this request is for a canonical URL.
Server builds a page and sends it to the user.
My company is embarking on a large website redirection at the moment and I decided it would give us the perfect opportunity to make the URL's more user and google friendly.
To give you a brief outline of the situation, I am the SEO guy and I am dealing with an external developer in order to redirect the website without hurting the current rankings in Google. I don't have much experience regarding sharepoint hence why I would really appreciate any assistance in understanding and knowing if there is a work around to my situation.
The website is using IIS7.5, they recently installed the URL Rewrite Module in order to create more user friendly URL's. My question is, by creating a more user friendly URL, does this cause an additional redirect?
For example: if a user types in www.domain.com this permanently (301) redirects to www.domain.com/pages/home.aspx.The developer told me that in order to rewrite the URL to display something more friendly (like www.domain.com/home) this will have to cause another permanent redirect. So in essence the process will look like this:
REQUESTING: http:// www.domain.com
SERVER RESPONSE: HTTP /1.1 301 Redirect
1) Redirecting to: http:// www.domain.com/pages/home.aspx
SERVER RESPONSE: HTTP /1.1 301 Redirect
2) Redirecting to: http:// www.domain.com/home
SERVER RESPONSE: HTTP/1.1 200 OK
Is this how the URL Rewrite Module really works? I would have thought that it would not have to create another redirect in order to create a more user friendly URL?
My second problem is this.... The redirect is happening on the same server. So here is essentially the situation:
www.old-domain.com
www.dev-domain.com
www.new-domain.com
The old-domain needs to be redirected to the new domain so we ran a test in order to see if the HTTP status codes were correct before going ahead with the project. So the developer redirected the dev-domain to the new-domain and the redirects look like this: (The developers comments in italic below)
REQUESTING: http:// www.dev-domain.com
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
1) Redirecting to: http:// www.new-domain.com/
SERVER RESPONSE: HTTP/1.1 302 Redirect
2) Redirecting to: http:// www.dev-domain.com/Pages/home.aspx
SharePoint’s alternate access mappings causes this to happen and there is no way around this.
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
3) Redirecting to: http:// www.dev-domain.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
4) Redirecting to: http:// www.new-domin.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 200 OK
The developer states the reason for redirecting back to the dev-domain then back to the new-domain is because of SharePoint's alternate access mappings and there is no way around this. Is that entirely true?
Any assitance at all will be GREATLY appreciated!