Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Are the two URLs equivalent with respect to browser caching and website seo?
1 - http://example.com/resource.html?a=a&b=b
2 - http://example.com/resource.html?b=b&a=a
If the resource for the first URL is cached and the browser needs to find the resource for the second URL can it use the cached resource? I want to know about the caching because I can ensure all internal links use the same parameter order to increase cache performance.
Also, if my server treats these URLs as the same resource, which URL will be indexed by Google? With consideration to SEO, will this count as duplicate content? If so, I could use a 301 response to redirect to the correct URL. (This should also fix the caching problem.)
If the resource for the first URL is cached and the browser needs to find the resource for the second URL can it use the cached resource?
That is not certain. It depends on each browser implementation. But if you always use the same parameter order, then it is not an issue in the first place.
Also, if my server treats these URLs as the same resource, which URL will be indexed by google?
Both will be indexed by Google, but if you use canonical links or if you configure parameters in Google Webmaster Tools, then they can be treated as one when displaying search results (i.e., Google will give the preference to one URL and it will collect the PageRank and other signals from the other).
With consideration to seo, will this count as duplicate content? If so, I could use a 301 response to redirect to the correct URL.
Yes, it will be considered as duplicate content, because the URLs are different. Using a redirect in this case is shooting flies with a canon (IMHO), but it would work.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 12 months ago.
Improve this question
I found out that there are servers that respond with HTTP 405 to HEAD requests (or another status code including 404 which is confusing IMO, but that's not important now) even though GET requests are responded with HTTP 200. HTTP 405 is defined as...
405 Method Not Allowed
The method specified in the Request-Line is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
Alright, I looked at the Allow header and found out that I can use GET to get the resource (even though I only wanted to find out whether the resource exists). Problem solved.
However, my question is... Why would a server disallow the HEAD method? What is the advantage? Are there possible security reasons?
I think it is because they're getting a log full of "the requested resource can only be accessed via SSL" errors when their HTTPS-only site gets tons of HEAD requests via HTTP. I think they're conflating "method" with "protocol" and so thinking the 405 makes sense.
See this post for an example of someone asking about the issue and being told to give a 405.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
After receiving a post request in servlet, I have to do a redirection to another server and at the same time I have to pass an xml file in the redirection request.
For example, I have to do a redirection from my servlet to "http://www.abc.com" and pass an xml file in the request.
I tried the following, but it didn't work.
response.sendRedirect - it is creating only get requests, so not able to send xml
HttpClient or URLConnection - it is creating a new request, not doing the actual redirection
Intermediate jsp - forwarded the request to a intermediate jsp and did a submit from jsp.
It is sending the xml in parameter and not in InputStream
Please let me know how to achieve this.
A redirect (either HTTP or HTML) can only operate on a URL, rather than a form submission, which offers built in support for uploading files via the "multipart/form-data" form encoding, and so you would have to encode your file within the URL itself, which would severely limit you given that the lowest-common-denominator (Internet Explorer) URL maximum length is around 2000 characters. If your files are smaller than that, then you could encode your file as a URL query parameter. Otherwise, it's probably not possible, but I will stand corrected if others know of a way to achieve it.
I found some info here: Redirect 301 with hash part (anchor) #, but doesn't really answer my question.
I created a SPA that uses Sammy.js for routing based on the URL hash. Now I have another page on my site (possibly other sites also) that collects some info from the user, then needs to redirect them to my SPA with a specific route. This other page is ASP.NET 3.5 so I'm using this code, which just does a 301 redirect:
Respone.Redirect("/#" + folderID);
It works correctly when I test in Firefox, but I don't currently have access to all major browsers, and also wondering if this will work with most proxies as well -- or will the proxy remove the #hash part from the URL?
I know the hash part is special and in some cases is client-side only. For example, I know I can't read the hash value that was set by JavaScript, in something like an ASP.NET postback, form submit, or AJAX request.
However, for this very specific usage where I'm not trying to read it, I'm just trying to set it.. is this widely accepted and robust? I know basic hyperlinks with hash tags work, even across domains, but of course those are not doing a 301 redirect (are mostly client-side) so not really the same.
I want to make some changes to my web site that requires some URL rewriting to keep my old URLs. I can't use proper URL rewriting because I have very limited control from my hosting provider.
As I'm using ASP.NET and all of my pages have the .aspx extension, one idea I had is to put something in the global.asax under the Application_BeginRequest event. This could check if the URL of the page requested is one of the old ones and use Server.Transfer to open the correct page.
My question is, would this transfer this invisible to Google? I don't want my ranking within Google to be affected.
Server.Transfer happens entirely on the server side, so any client (including Google) will not be aware of it.
The client (browser or bot) won't have any idea whatsoever that the Server.Transfer occurred. It will see only that it requested a given URL and got the content you return. There's no response to the client saying that you've moved things (that would be Response.Redirect).
In your case, it sounds like that would mean you'll have two URLs returning the same content — two identical pages — which could affect how search indexes treat the content (and certainly means you'll end up with people linking to both URLs, which could impact the rank of each URL).
You can address that by specifying what the canonical URL for the content is. More in this Google blog post, but basically, if you have both http://example.com/foo.aspx and http://example.com/bar.aspx returning the same content, and you want the canonical (official) URL to be http://example.com/bar.aspx, tell the indexers that:
<link rel="canonical" href="http://example.com/bar.aspx" />
Google is only bothered about the Page Content, It does'nt bother how the content is constructed on the web server. Since Server.Transfer is completely internal to a web request, i think you should be okay with your website rankings.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
The question can be seen as both practical and theoretical.
I am designing a system involving a HTTP client (Flash Player application) and an HTTP server "backend". There are registered users each with their own private image library. Images can be uploaded and of course subsequently retrieved.
Since users authenticate with cookies carrying session identifiers, it suddenly became clear to me (and hence the question) that I can provide the following kind of URL for an authenticated client to retrieve an image ('asset' in my terminology). Note that asset identifiers are unique even across users, i.e. no two users will both have an asset with ID of say, 555. Also, an asset identifier is assumed to be REALLY persistent, i.e. the ID is non-reusable. The URL I was thinking of is:
http://myserver/user/asset/<asset_id>
Brackets denote variable value, i.e. obviously these and the 'asset_id' are not to be taken verbatim here, they denote the actual asset identifier. The HTTP request "to" the above URL is expected to carry a cookie header with the user session identifier, which uniquely authenticates and authorizes the user as the owner of the asset requested.
I am very much after permanent URLs ("Cool URIs don't change" as Tim Berners-Lie said once), but obviously, since the asset resources are private to the user that uploads/owns them, they are not to be cached by any intermediate proxies, only user agents.
Can we consider the URL above as a good way to identify a user asset? My worry is that the response will vary depending on whether a valid session identifier cookie header is supplied or not, and so there is not a one-to-one relationship between the URL and the response. But there is not much one can do, is it? Server HAS to check that the user is authorized to retrieve the asset, right? If you guys have any better suggestions for a solution here, I am also anxious to hear it. Thanks.
you've said it all, I wouldn't change a thing about your strategy :-) If an unauthorized user tries to access some asset, simply give him a 403 http code ... that's the correct and expected response in that case
Just becaues a URL doesn't change doesn't mean that every request to that URL must be successful (or even return the same object/asset).
You can easily use that as an identifier and simply tell un-authenticated clients that they are 401 Not Authorized or even that they can't access it at all: 403 Forbidden.