I have an MS-Word document with a hyperlink. The hyperlink points at an authentication redirector on my server. When I control-click on the hyperlink, my server logs report that it
does a fetch with IE, then
fetches the redirect url with IE, then
launches the "default browser", which is Firefox in my case, and re-fetches the second (redirect) URL.
What gives? Is this by design?
I noticed this because my auth system is currently dependent on cookies set by the redirector. I have some ideas about using url-based auth for this bit, but I need to know what is motivating Word's behavior first.
I have some guesses but I'm looking for something authoritative (or at least a better-informed guess).
Unfortunately, yes. And they try to blame it on "a limitation of the single sign-on system used by the web server"...
http://support.microsoft.com/kb/899927
Actually, this is a "feature". If the hyperlink is to a Word document, word will attempt to download the document and open it. (You must be thinking it's IE because of the user-agent, but the request is coming from WinInet in the the Word process.)
The mess comes about when the server doesn't respond with a page, but rather responds with a redirect and cookies. Word follows the redirect to see if it's going to get a Word document, and it eventally ends up with an HTML page. It then decides that Firefox should display it, so it launches Firefox with the final redirected URL, (but without any of the cookies that the server sent).
Firefox may end up needing those cookies, if this is an SSO sign-on.
Late addition:
Noticed the same problem. Here with MVC 4 it caused the loss of querystring information.
Word launches the browser only after it receives a Http 200 status.
So I avoided this by checking in the controller whether the request comes from IE7 (representing likely only to be MS Word) and returning a 200 manually.
Then the 'real' browser will re-send the http request and all's well ends well, since from there the request is processed normally and all information is retained in the session with the 'real' browser.
Bit of a workaround, but hey, it works. And it's only for a small amount of requests (in our case).
Related
Very new to Coldfusion, but not to web development so hopefully this is an easy question.
We recently changed a link on our website that took us to /folder/index.cfm. I want to make sure that when someone types www.ourwebsite.com/folder that it doesn't take them to /folder/index.cfm and instead to redirect them to another website.
Any pointers?
There are at least three ways it to do this.
Don't even bother with ColdFusion. Have your web server do the redirect. You are going to need to know if it Apache or IIS or whatever. You can then search for how that web server does it.
This might help you with some of that: Custom 404 error page not working on IIS 8.5
You can make a file at /folder/index.cfm and have a file that has
OR with cfscript
<cfscript>
location("newpage.cfm", false, 301)
</cfscript>
Note the addtoken and statuscode are optional. Add token helps because almost no CF website uses this kind of token. The status code helps because tells the browser that this is a permanent move.
You could intercept the request in application.cfc . In fact, in some systems all requested are checked for validity in application.cfc. You might still need a blank page at the target, but at least some ColdFusion is processed
Of all the options, 1 is my favorite, because there really isn't a lot that can be done with requests to missing pages. And the list of potential missing pages is unlimited.
I am trying to use some webviewers on Filemaker WebDirect. I would like to call a script in filemaker from a button on the webviewer. It works great in pro but I'm not sure of the url protocal I need to use in web direct. What is the format I should use when trying to call a filemaker script from a webviewer in webdirect?
You'll need to test this out because I haven't tested it, but I believe that when you use a webviewer in a WebDirect solution the webviewer actually displays an iframe tag and the contents of the webviewer works like any other iframe on a webpage, i.e. it's no longer part of the WebDirect application.
You can check it out in the browser interface of your WebDirect solution by right-clicking on the webviewer and selecting "inspect element". That should open up the browser's developer tools and show you the webviewer's element in the overall HTML structure. The webviewer should be an iframe.
All of that said, if it does treat the content of the webviewer as an iframe and therefore the content of the iframe is outside of your WebDirect solution, it means that whatever communication you have from the webviewer content would need to communicate externally with your FileMaker Solution via XML custom web publishing. It would be like standing inside of your house, reaching out of a window, unlocking your front door, and grabbing something you want.
This means you would need:
Web Publishing turned on on your FileMaker Server
A user with the xml extended privileges enabled
An external IP address that you can access your FileMaker Server by
Then you could (again, theoretically I have not tried doing this) use a link that contains a url with the XML custom web publishing syntax to perform the script. You can find a description of the syntax in the FileMaker Server documentation PDF fms13_cwp_xml.pdf. I can't find a good link to the syntax online at the moment, but you could search around for it. The basic syntax outlined in the PDF is:
<scheme>://<host>[:<port>]/fmi/xml/<xml_grammar>.xml[?<query string>]
and calling a script would look like:
http://myfmsdomainname.com/fmi/xml/fmresultset.xml?-script=theScriptIwantToFire
My url structure could be off.
Anyway, it sounds like it could be a pain in the ass, but it may be a solution! Good luck!
This is tricky because you will have to communicate with the Webdirect client via FMServer!
Use the FMServer PHP interface for your webpage within the webviewer to communicate to the server. Your web page can either:
1) Directly set a value in the server that your client will monitor
2) If it has to call a script then call a script on the server, your client will still have to monitor a value. e.g. use the php API on your webpage. Setup your database connection (see the API docs in your FMServer folder for an example), then call:
$newperformscript =& $fm->newPerformScriptCommand($layoutName, 'scriptname',$scriptParameters);
$result = $newPerformScript->execute();
Your Webdirect Client will then need to monitor for that change. While Webdirect is on the layout with the webviewer, your client could use the filemaker script step to actively monitor for a change in value via a timer:
Install OnTimer [Interval:secs]
When your client detects that change that you made then perform your action.
Note: You will have to pass an ID of the client to the webviewer, and your webviewer will have to pass that ID back to the server, and your client will have to monitor for that ID so that all clients don't respond to the change. You can pass whichever client ID you choose to use to the webviewer via the URL using GET.
If your server is local then the change will be detected in one second if that is what your Install OnTimer timer is set to.
What you are doing is far from ideal with Filemaker... I suggest that you look into a different UI paradigm if possible.
I tried to find out this, and got that http://www.google.com/ncr uses 302(or 301) redirections(not sure if it really is).
and i also got that, the server side redirections(301 and 302) will not change the original referer, i.e. if i visit http://www.google.com/ncr directly, then the request goes to google.com, but nothing in the header can show that i come from http://www.google.com/ncr.
so i wonder how google do this.
People do this very often with servlets. The servlet would detect a certain pattern and issue a redirect to a conglomerated url. A redirect is directed at the browser. It's like the browser has activated/clicked on a new link.
It is like you entered google.com/abc on the url bar and then entered google.com on the address bar after that. Due to privacy issues, the browser does not let the server know what previous URL it has visited.
Of course, if you are on the same session, going to the same site, google would have both server side and client side cookies tracking you that you just came from another google url. If were a web service provider, I Would certainly exploit knowing your browsing history.
So that, due to your browsing history www.whatever. com would redirect to different pages for different users or sessions.
Addendum:
"Due to privacy issues, the browser does not let the server know what previous URL it has visited." is not quite correct.
The more complete spec is
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
Another reason why google forcing us to use https benefits us.
Redirect flow of non-secure http
Let's say we have
URL A has a link goto B with leads to URL B.
URL B is a redirect to URL C
The server of URL C will see the referer as URL A, not URL B. That is, the browsers will set the referer to URL A.
Redirect with cookies
I believe you should be able to include a setcookie header on a 30x redirect. I have not tried it so I do not know which browser will ignore or honour it.
BTW
I have great doubts that my answer is satisfactory for your question. I personally feel it is incomplete and I hope some one comes up with a better answer and you should choose that as the answer. In fact, I think you should unchoose this as the answer so that your question gets back into the pool of unanswered questions. Sorry.
If I create a basic asp.net application and set the #outputcache the page is cached fine in chrome & IE on the desktop. First request returns 200, subsequent request return 304 for the default.aspx. (I'm monitoring through fiddler)
However accessing the same page from an iPhone I noticed that it's always returning 200 for the aspx file. All resources are being caching and are returning 304's. So it's just the aspx page.
Any ideas why this is happening?
Some technical details:
<%# OutputCache Duration="30" VaryByParam="None" Location="Any" %>
Stock standard ASPX page. Content-Length: 2464
Reloading on the iPhone using refresh control or keyboard "go" doesn't make a difference.
Explicitly setting eTag does not make a difference
Last-Modified is set
but If-Modified-Since is not being send for the ASPX page
Latest IOS 4.3.1
IIS 7.5 running on Win7 using ASP.NET 4
I think I figured it out. Feel free to correct me however. Website caching is a very messy area.
The root of the problem is that the iPhone is not sending "If-Modified-Since" headers with it's requests. Without that the server cannot reply with a 304.
After some experiments I've found that if you use a link to navigate to the page it will send the 'If-Modified-Since' header and everything works as expected and the server neatly returns a 304.
Cases where it does not send a "If-Modified-Since" even though it's cached:
Typing in the URL
Pressing the refresh button
Selecting the URL and pressing Go
Opening as a bookmark
Opening from a saved reference on the home screen
It only seems to be doing this for the primary url everything else that is referenced does have a "If-Modified-Since" header (where applicable).
Note: I've tested this on IOS 4.3.1 only. Looking at the link Paddo send and further investigation into that area it seems that Apple likes to change caching behaviour between IOS versions.
Found this, re php (will also apply to .net)... iphone doesn't seem to cache any resource over 15k in size, and total cache size is 1.5MB. Note this is old information so may have changed.
http://www.phpied.com/iphone-caching/
The solution for a file over 15k, is to use an offline application cache manifest file, as outlined here:
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/Client-SideStorage/Client-SideStorage.html
PS I know your content length is below 15k - so something else must be amiss... but I'm still hopeful that the manifest file will work.
for ASP.NET just use
Response.AddHeader( "Cache-Control","no-cache");
or
Response.AddHeader( "Pragma", "no-cache");
or
Response.Cache.SetCacheability(HttpCacheability.NoCache);
My client's website opens external links in new windows (with target="_blank"). The links are also routed through a logger which responds with a 302 redirect to the desired page.
For example, instead of
...
We have
...
Where /redirect?to=$url returns an HTTP 302 to $url.
This works fine in all browsers except IE8. Instead of opening a new window with the desired URL, IE8 opens a new window and stalls with a progress throbber and an empty address bar. If I then hit stop and reload, the desired URL loads.
Has anyone encountered this problem? Is there a known solution that preserved my client's desired behavior? That is, to open links in a new window with redirect-based logging.
I know it's just a workaround, but... use JS redirection if the browser is IE8?
Watch your traffic in a network traffic debugger like Fiddler2 to see what's happening on the wire. You can then add the exact raw text of the HTTP response to your question to help with replicating your results.
Also, is this redirection crossing between IE security zones (e.g. Internet,Intranet, etc)? In particular, it's always interesting if a redirection crosses (Vista+) from a Protected Mode Zone to a non-Protected Mode zone, as this goes through a rather obscure codepath in IE.