Thought is was time to bring this to the Stack. We have IIS 7.5 (classic mode), .net 2.0 on Windows Server 2008. The app was upgraded from .net 1.1 with no issues/changes needed. It was migrated from Server 2000. Once in its new home, Forms Authentication started to hiccup for IE users. IE users can log in, arrive at the successful login destination page which has a paragraph of text, a WebControlLibrary sound bit (mp3) and an asp button. Upon button click, IE users are immediately sent back to login. It happens so fast, does not appear to postback, but fiddler says it does and shows it posts back twice with a sneaky 302 redirect mixed in.
On fiddler, Firefox shows no 302s and works fine as does Chrome. This only happens externally to our network as well, on IE7/8, internal testing is fine.
I have seen where users have reported that an underscore in the url can cause this..don't have one. Mixing authentication modes in IIS 7.5 can cause issues, we use classic mode. I have seen where javascript used to call the postback for the button can cause this, we use standard .net button onclick event in code behind (that simply checks a page number then does a response redirect to the next page in the app.)
I have roamed google and bing (and here) for the better part of a few days to no avail. I apologize for the vagueness of the question.
EDIT:
No underscores in server name. Here is the process as visible by a user. You Login, login page refreshes and asks you to verify you are who you say you are. If you say yes, you go to instructions.aspx. This pages buttons will postback as you hit "continue". IE dies on first conitnue click and note the odd stuff in fiddler...FF is fine and moves on to rest of app.
IE 8
Result Protocol Host URL Body
200 HTTP CONNECT / 0
200 HTTPS xxxxxx.com / 12,354
200 HTTPS xxxxxx.com /login.aspx 8,139
302 HTTPS xxxxxx.com /login.aspx 137
200 HTTPS xxxxxx.com /instructions.aspx 6935
302 HTTPS xxxxxx.com / 131
302 HTTPS xxxxxx.com /logout.aspx 130
200 HTTPS xxxxxx.com /login.aspx 12,354
302 HTTPS xxxxxx.com /insturctions.aspx 167
200 HTTPS xxxxxx.com /login.aspx?ReturnUrl=&...
FireFox
Result Protocol Host URL Body
200 HTTP CONNECT / 0
200 HTTPS xxxxxx.com digicert.com 12,354
200 HTTPS xxxxxx.com /login.aspx 8,139
302 HTTPS xxxxxx.com /login.aspx 137
200 HTTPS xxxxxx.com /instructions.aspx 6935
200 HTTPS xxxxxx.com /images/xxx.jpg 47
200 HTTPS xxxxxx.com /images/xx2.jpg 46
200 HTTPS xxxxxx.com /instructions.aspx 12,354
200 HTTPS xxxxxx.com /images/xx3.jpg 49
It appears that as of IE8, the forms tag attribute "domain='domain.com'" is required. Found this blob post Persistent Cookies Fail in IE8 and Windows 7
and this has solved the issue based on prelim testing.
The _ issue is not for the URL... it is for the server name. Can you please check and confirm if that's not the case?
Also install Fiddler (www.fiddlertool.com), and browse the site from IE. Save the logs. Clear the logs now... browse the site from Chrome, and save it again. Once done with this exercise, check and compare the logs.
[I can help if you send me the logs saved as suggested from fiddler]
Related
I developed my own HTTP server under Windows\Linux.
The problem: after entering the URL in Chrome, I have to refresh 2 or 3 times until the page is loaded.
If I'm using Microsoft HTTP server or Apache (for Linux) it works always on the first refresh.
Is there a specification that I should implement?
According to few links I found, there is no way to set timeout in Chrome.
I have an application which is accessed via HTTPS, but is "reverse proxied" to the server using plain HTTP. It is set up on AWS as follows:
[BROWSER] --(https)--> [ELB] --(http)--> [SERVER]
Everything works fine except when a page is being accessed by an unauthenticated user, the server responds with a HTTP 302 redirect using the whole protocol://server/path string. Like so:
Location: http://my.server.com/Account/Login?ReturnUrl=%2F
The problem is, it specifies HTTP as the protocol (presumably because it is being connected to by the ELB using HTTP. So the browser redirects the request using HTTP and now an error occurs. Is there a way to customize the redirect such that it redirects using just the path, so irregardless of protocol or hostname, it is redirected properly? Like so:
Location: /Account/Login?ReturnUrl=%2F
If this is not advisable, what can be done?
(note: I've checked other solutions posted on SO. All I've seen so far involve customizing the Path, not removing the protocol://hostname)
I'm trying to leverage a Wordpress plugin that does image shares called Share This Image (codecanyon.net/item/share-this-image-image-sharing-plugin/9988272). This plugin utilizes LinkedIn's custom URL sharing tool using "ShareArticle".
The use-case is the visitor visits the page, hovers over the images in the right hand of each "Objective" and clicks one of the social media links. This generates a popup which, for Facebook and LinkedIn is supposed to provide a custom message and image.
It seems to work beautifully on our staging site, but not on the live site - at least not for LinkedIn (Facebook is fine.) The live site only displays the domain name and nothing else when clicking on the LinkedIn share.
I've talked with our hosting provider who made sure we had no caching in place on our end on the live site (staging has no caching by default) but it still doesn't seem to work like our staging site does. I also tried copying our live site to new space (in case there was some oversight in differences between live/staging) and it works just fine. I've also been talking with LinkedIn sales reps we know and they're stumped as well. They suggested posting here.
Given all of this, I'm wondering if there isn't something "stuck" on the LinkedIn side. Perhaps something cached within the bot?
Note that I get the same effect when trying to share the target URL directly in a status update at www.linkedin.com. Without seeing what the LinkedIn bot is seeing, it's difficult to troubleshoot. When I paste the URL that we're passing to LinkedIn I get the proper result in my browser.
Our staging site is: amapatients.staging.wpengine.com
Our live site is: www.patientsbeforepolitics.org
The URLs the plugin is generating for the LinkedIn share (using Objective 2 as the example) are:
Staging LinkedIn window opens with:
Staging Site Popup
Live site LinkedIn window opens with:
Live Site Popup
Other than paths, the code is basically identical between the sites but the live site is SSL encrypted.
Noting that on some browsers the LinkedIn pop-up just does an endless loading screen that doesn't stop.
I noticed that the times it does work, it only shows the TLD, not the full "www.patientsbeforepolitics.org". The TLD is using domain forwarding through GoDaddy - is that possibly an issue? Are generally 301 redirects problematic?
I'm a developer at LinkedIn, and I've had a chance to look at this case. Your suspicion about the 301 redirect matches what I am seeing on my side as well.
When I use curl or a web browser to fetch the url, the live site responds with a 301 redirect, like this:
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html
< Date: Thu, 23 Mar 2017 15:04:16 GMT
< Location: https://www.patientsbeforepolitics.org/wp-content/plugins/Share-This-Image/sharer.php?url=https%3A%2F%2Fwww.patientsbeforepolitics.org%2F%2315535&img=www.patientsbeforepolitics.org/wp-content/uploads/2017/03/Objective1.jpg&title=AMA%20Patients%20Before%20Politics%20Obj%201&desc=Ensure%20current%20levels%20of%20coverage%20%20coverageaccess%20for%20uninsured&netwoe
However, when our server fetches the url, we identify ourselves using a different LinkedInBot user-agent string.
And the response that we get to our request is different:
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html
< Date: Thu, 23 Mar 2017 15:00:17 GMT
< Location: http://www.patientsbeforepolitics.org/wp-content/plugins/Share-This-Image/sharer.php
All the parameters have been stripped off the redirect location, so that when we then try to follow the redirect, we hit a dead end, and we don't get the data we need to create the correct share on LinkedIn.
So, this 301 redirect that returns a different location for our LinkedInBot user-agent seems to be the reason why your live site is giving you different results from your staging site, which doesn't have a redirect. If you are able to configure your site to handle our user-agent the same as a web browser, sharing on your live site should work too.
I hope this helps.
Why would a site respond with an HTTP 302 (redirect) and include HTML in the payload. Check out godaddy.com. You will need an account to log in. When you log in you will see in an HTTP trace (I use firebug), a 302 returned with the location: header as expected, however the payload includes the complete HTML page. Next, as expected, you see the URL from the location header fetched with the same HTML payload. Why would they do that?
I don't know anythign about GoDaddy but it may be a way to somewhat post information back to their server but not force your browser to do an "auto form post". I'm working with ADFS currently and with that security (and many others) the authentication authority sends back a 200 with html of a form, which when loaded immediately posts that form to your server.
I'm currently experimenting with sending back a 302 with the payload that redirects back to the server instead. This prevents a flash of white as that auto-post is taking place.
It's just a guess :)
The whole thing started when I noticed Facebook Debugger and other crawler tools are unable to parse my page. Facebook throws a critical error saying that it cannot follow the redirect. I believe Search Engine bots are hitting the same end. The website is functioning normally via all major web browsers.
It's probably worth to mention I am experimenting with ASP.NET Routing, using Web Forms under IIS8.
Given a website (http://example.com), here's what happens.
Case 1: Trying to access the root, this is what I get with a Web Sniffer simulator
Case 1 observations:
First thing I notice is '302' redirect instead of '200 OK'. It gives a 302 redirect with or without leading 'www'.
I noticed is that the Location Header is simply "/", confirmed by the page from IIS that I cannot see with a regular browser, which says the page is moved to "/". I believe something messes up at this point and the crawler is unable to follow through for some reason.
Case 2: Trying to access a given category page with a Web Sniffer simulator
Case 2 observations:
As you might figured out already, identical to case 1. And once again Facebook debugger cannot go through it, resulting to a redirect it cannot follow.
Questions:
1: How can I force an absolute path in the location headers instead of relative and will this be sufficient for the crawlers to follow through?
2: What could cause a 302 redirect happening in the first place in both www and non-www versions of the website?
Your web application is most likely depending on a cookie. The application sends a Set-Cookie header and redirects to the same page in order to receive a new request with the cookie data available. Search engines / bots, the Facebook bot and your Web Sniffer simulator will not send that cookie data and hence the web application keeps sending the 302 redirect responses.
The solution is to change your application to not require cookies for just simply viewing your web pages.