I'm consistently receiving HTTP 303 ("See Other") redirection to HTTP 500 error responses from our Valence API when trying to retrieve the structure for a handful of modules. (Handful = 20-30 modules out of about 19,000). The ones that fail consistently fail, but can be viewed through the web UI without issue.
Here's a cURL request of a failing request:
GET /d2l/api/le/1.4/420523/content/modules/2872608/structure/?x_a=...&x_b=...&x_c=...&x_d=...&x_t=... HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.18 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: d2l.deakin.edu.au
Accept: */*
And the response:
HTTP/1.1 303 See other
Cache-Control: private
Content-Length: 0
Location: /d2l/error/500
Server: Microsoft-IIS/7.5
X-XSS-Protection: 0
X-Powered-By: ASP.NET
Date: Mon, 16 May 2016 05:13:37 GMT
The modules that I've looked up in the web UI don't seem any different to any other module, for example a module might contain 3 sub-modules, all with topic-only content, and one of the modules gives a 303 response, 2 do not.
There are a couple of org units with 2 or 3 "bad" modules, but mostly they're singular.
I've also tried this at API versions 1.1 -> 1.4 (we are currently on v1.4)
I also raised a support call with the vendor for this issue.
It turns out to be a bug in Valence API versions <= 1.4, triggered by a module containing a topic file which ends in a dot/period (hence having the form some_file..ext once its given an extension).
Solution: upgrade to Valence 1.6 where the bug is fixed, or rename affected files.
Related
I have two DotNet MVC sites. One accesses a Web API from the other with an AJAX GET call.
This all worked, but has stopped functioning now. I've hardly made any changes on my side, so I'm wondering if my host might have made changes (in IIS, for example) that would stop this from working?
Here's how I initially got it working...
I installed the Microsoft.Aspnet.Cors and Microsoft.Aspnet.WebApi.Cors packages.
I added the following code...
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.EnableCors();
And in the controller for my API I added...
namespace Webscope.Controllers
{
[EnableCors(origins: "[URL of my other website]", headers: "*", methods: "*")]
public class EventAPIController : ApiController
This used to work, but now get the following error in the console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https:[my website URL]/EventRead/1-1-2015/12-12-2099. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
In response to #FoggyDay's answer below, I've called the API from Fiddler and got the following headers...
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Frame-Options: AllowAll
X-Powered-By: ASP.NET
Date: Fri, 13 Mar 2020 03:56:39 GMT
Content-Length: 198
So it looks as if CORS headers have not been included in the response. Can anyone tell me why this would be?
UPDATE
I found some extraneous code from a previous attempt to get CORS working. Now that I've removed this code, I am seeing the CORS headers in Fiddler.
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: https://[ calling website's URL ]/
However I'm still getting the following error in my calling site's console...
Access to XMLHttpRequest at
'https://[ destination site URL ]/api/EventRead/1-1-2015/12-12-2099' from
origin '[ calling website's URL ]' has been blocked by CORS
policy: Response to preflight request doesn't pass access control
check: No 'Access-Control-Allow-Origin' header is present on the
requested resource.
SUGGESTIONS:
Back out your "new" changes. It sounds like you've inadvertantly introduced a second header.
Read this: Reason: CORS header 'Access-Control-Allow-Origin' missing
Look at your HTTP traffic, for example in Fiddler. Verify that you're sending the header ... and verify that you're allowing the correct combination of host and port.
If you're still having problems, post back with the exact error message and relevant HTTP headers.
I've got a weird problem in Microsoft.AspNet.WebApi{5.2.3}. The following two functions work fine alone, and they even work fine together, when my client is a .NET 4.6 HttpWebClient. However, as soon as a Java application tries to access the function, I get the following message:
HttpResponseProxy{HTTP/1.1 405 Method Not Allowed [Allow: GET,
Content-Length: 73, Content-Type: application/json; charset=utf-8,
Server: Microsoft-IIS/8.0, X-Powered-By: ASP.NET, Set-Cookie:
ARRAffinity=2cc8b96e3a4c1d6ee6a6e0;Path=/;Domain=mydomain.com, Date: Mon, 01
Feb 2016 13:44:57 GMT] ResponseEntityProxy{[Content-Type:
application/json; charset=utf-8,Content-Length: 73,Chunked: false]}}
It looks from the error message, that a GET is being tried (or expected?)?
I have added the explicit routing attribute as a last resort. I do not use it elsewhere.
Function 1:
[System.Web.Http.HttpPost]
[System.Web.Http.Route("api/Delegate/MigrateMix2User")]
public async Task<HttpResponseMessage> MigrateMix2User([FromBody] MigrateUserModel userInfo)
{...}
Function 2:
[System.Web.Http.HttpPost]
[System.Web.Http.Route("api/Delegate/ChangeUserEmail")]
public async Task<HttpResponseMessage> ChangeUserEmail([FromBody] ChangeEmailModel model)
{...}
Update Http Traces. Content doesn't look like a cause/problem?
Content usage traces: --- .NET 4.5 HttpClient, works fine:
POST http://localhost:1655/api/Delegate/MigrateMix2User HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsI...bE6s
Content-Type: application/json; charset=utf-8
Host: localhost:1655
Content-Length: 231
Expect: 100-continue
Connection: Keep-Alive
{"r_tc_app_client_id":"TN77PENKGu2Nq525c6Za93jbD7PiHzSo","r_email":"hyxx#acx.org","r_password":"dada","r_lang5":"en-EN","r_country2":"US","r_is_cto":"false","my_cto":"xzy","r_plan_id":"planet","addin_plan_id":"tst","addin_qty":2}
--- Java-Appache http Client: throws 405
"POST /api/Delegate/MirgrateMix2User HTTP/1.1[\r][\n]"
"Authorization: Bearer eyJhbGci...dIRiJE[\r][\n]"
"Content-Type: application/json[\r][\n]"
"Accept: application/json[\r][\n]"
"Content-Length: 274[\r][\n]"
"Host: mytargethost.com[\r][\n]"
"Connection: Keep-Alive[\r][\n]"
"User-Agent: Apache-HttpClient/4.3.6 (java 1.5)[\r][\n]"
"Accept-Encoding: gzip,deflate[\r][\n]"
"{"cto":"true","r_tc_app_client_id":"G04o5323zq1fo6hferi4axABdKvyiSCl","r_email":"kunsbe1#mailinator.com","r_password":"2Mh323aXp","r_lang5":"en-US","r_country2":"DE","r_is_cto":"true","r_plan_id":"05260000_LOR.2001","addin_plan_id":"05260000_LOR.2007","addin_qty":815}"
DEBUG [org.apache.http.wire] http-outgoing-2 << "HTTP/1.1 405 Method Not Allowed[\r][\n]"
2016-02-02 12:49:56,914 DEBUG Wire - http-outgoing-2 << "HTTP/1.1 405 Method Not Allowed[\r][\n]"
Based on the error message it's because you have marked your methods as HttpPost (verb POST) but your javascript is accessing these using GET (HttpGet).
You should include your java code if you want an exact fix in your calling code.
OK, the enigma is solved and I want to share the result. In the end, the solution was this post however, there is more to it: you see, the Java folks had a typo in there calling URL the whole time. However, they never noticed that it was the wrong function name since we were getting a 504 response status and not a 404. Also, when we commented out the second POST function in the WebApi Controller, it worked fine. And to make things more confusing, the error message said that the problem was due to a HttpGet being refused and the Java system was definitely sending a HttpPost. So here is what we learned: the WebApi Controller apparently lets any authorized POST call a single POST function, regardless of the name of the function. I suspect that the WebApi 2 default behavior is probably not intentional. Anyway, it led us off track since we assumed that the function name and URL were ok since the function was, after all, being executed. After making the changes in the link above, we started to get 404 instead of 504 and the source of the problem became evident... We didn't know whether to laugh or cry :-)
I have an issue similar to Heroku & Rails - Varnish HTTP Cache Not Working, but the solution (wait for a while, then everything works) doesn't seem to apply - I've had the setup below for several days.
This thread on the Heroku Google group has some users with the same problem. They mention that it takes a while for everything to be cached, but my understanding is that after a while, everything should get cached, no? Or does that only apply if there is a Lot of traffic?
I need some advice on where I should be looking/what I can try changing in order to get caching working properly.
My setup:
I have http://www.swingoutlondon.co.uk running on Heroku (Rails 3.0.3, Ruby 1.9.2, bamboo-mri-1.9.2) and the main index page performs a lot of database queries to return what is essentially a static page - usually taking about 2-3 seconds (yes, that's something I really do need to address, but I figure varnish caching is a quick win).
I've set the Cache-Control response header as described here, and indeed that does seem to have been set on the page:
>> curl -I http://swingoutlondon.co.uk
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 13 May 2012 00:01:05 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: public, max-age=300
Etag: "2565201f3ae39c6a9a1f6b1fb8bbbe0a"
X-Ua-Compatible: IE=Edge,chrome=1
X-Runtime: 1.699667
Content-Length: 44224
Accept-Ranges: bytes
X-Varnish: 681634826
Age: 0
Via: 1.1 varnish
Note: Cache-Control: public, max-age=300
I assume that Age: 0 indicates that it hasn't retrieved a cached copy, and indeed the command returns in the normal slow 2-3 seconds.
If keep repeatedly trying that curl, I can occasionally a cached copy (the page loads in under half a second and Age is greater than 0).
I must confess to not fully understanding HTTP headers, but one clue might be: when Age is greater than 0, I get two lots of digits in X-Varnish (in all other cases I only get one set):
X-Varnish: 848670407 848650521
Here's what I've checked:
the source of is identical each time.
I have one before_filter on that page, which sets the time the page was last updated as an instance variable.
there are a number of cookies - as far as I can see they are all set by either Google Analytics or the Twitter or Facebook buttons.
For good measure, here are my Request headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:__utma=264326157.189257391.1336869624.1336869624.1336869624.1; __utmb=264326157.2.10.1336869624; __utmc=264326157; __utmz=264326157.1336869624.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Host:www.swingoutlondon.co.uk
If-None-Match:"2565201f3ae39c6a9a1f6b1fb8bbbe0a"
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19
Ah well - turns out that because Heroku uses multiple independent Varnish servers, and because traffic to Swing Out London is relatively low, I shouldn't expect to have many pages served by the caches if my max-age is only 5 minutes. Setting it to 20 or 30 minutes results in much more caching.
I've written a detailed blog post collecting my learnings. Thanks to Garry Shulter for helping me out with this one.
Trying for hours to get a request token using Google OAuthGetRequestToken but it always returns "signature_invalid".
For a test I use the oAuth Playground to successfully request the token. Here are the results:
Signature base string
GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken&oauth_callback%3Dhttp%253A%252F%252Fgooglecodesamples.com%252Foauth_playground%252Findex.php%26oauth_consumer_key%3Dwww.embeddedanalytics.com%26oauth_nonce%3D56aa884162ed21815a0406725c79cf79%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1321417095%26oauth_version%3D1.0%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Request/Response
GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="56aa884162ed21815a0406725c79cf79", oauth_timestamp="1321417095", oauth_consumer_key="www.embeddedanalytics.com", oauth_callback="http%3A%2F%2Fgooglecodesamples.com%2Foauth_playground%2Findex.php", oauth_signature_method="RSA-SHA1", oauth_signature="qRtorIaSFaQdOXW1u6eMQlY9LT2j7ThG5kgkcD6rDcW4MIvzluslFgYRNTuRvnaruraNpItjojtgsrK9deYRKoHBGOlU27SsWy6jECxKczcSECl3cVAcjk7dvbywFMDkgi1ZhTZ5Q%2BFoD60HoVQUYnGUbOO0jPXI48LfkiA5ZN4%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 16 Nov 2011 04:18:15 GMT
Expires: Wed, 16 Nov 2011 04:18:15 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 118
Server: GSE
oauth_token=4%2FmO86qZzixayI2NoUc-hewC--D53R&oauth_token_secret=r0PReF9D83w1d6uP0nyQQm9c&oauth_callback_confirmed=true
I am using Fiddler to trace my calls. It returns the Signature base string:
GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken&oauth_callback%3Dhttp%253A%252F%252Fgooglecodesamples.com%252Foauth_playground%252Findex.php%26oauth_consumer_key%3Dwww.embeddedanalytics.com%26oauth_nonce%3Dl9Jydzjyzt2fJfM3ltY5yrxxYy2uh1U7%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1321417107%26oauth_version%3D1.0%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Aside from the oauth_timestamp and oauth_nonce (which should be different), the base string are pretty much identical.
Anyone know what I am doing wrong?
Update 11/20/2011 Thinking it might be something wrong with my RSA-SHA signing, I have since tried HMAC-SHA. It gives the same results. I thought it might be beneficial to include the Fiddler results (I added carriage returns to have it format better).
GET https://www.google.com/accounts/OAuthGetRequestToken?
scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_version="1.0",
oauth_nonce="7C4C900EAACC9C7B62E399A91B81D8DC",
oauth_timestamp="1321845418",
oauth_consumer_key="www.embeddedanalytics.com",
oauth_signature_method="HMAC-SHA1",
oauth_signature="ows%2BbFTNSR8jVZo53rGBB8%2BfwFM%3D"
Host: www.google.com
Accept: */*
Accept-Encoding: identity
Response
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=UTF-8
Date: Mon, 21 Nov 2011 03:16:57 GMT
Expires: Mon, 21 Nov 2011 03:16:57 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 358
Server: GSE
signature_invalid
base_string:GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken
&oauth_consumer_key%3Dwww.embeddedanalytics.com
%26oauth_nonce%3D7C4C900EAACC9C7B62E399A91B81D8DC
%26oauth_signature_method%3DHMAC-SHA1
%26oauth_timestamp%3D1321845418
%26oauth_version%3D1.0
%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Update 11/24/2011 - I want to add more information based on the answers from #Meysam and #Bob Aman. First, my domain is properly registered with Google. I have been using AuthSub for quite some time now with Target URL path prefix set to http://www.embeddedanalytics.com/authsubsuccess.html. Now when I go to the Manage Domains section it states my oAuth consumer key is www.embeddedanalytics.com. Now perhaps this could be a problem. In the Registration for Web-Based Applications document it states:
If you're using the OAuth interface, this URL (the "Target URL path prefix") must match the value of the oauth_consumer_key parameter
In my case I have a target URL different from my oauth_consumer_key. Could this be a problem? I use www.embeddedanalytics.com as the consumer_key in the playground and it works. I don't want to mess with the target URL because it is currently being used with my AuthSub authorizations.
I assume you have not registered your application domain with Google. Therefore, whatever consumer secret you are using to sign your request (in HMAC-SHA1 method) will be denied unless you provide anonymous as your oauth_consumer_key and consumer secret. This way, Google will recognize you as an unregistered application and will successfully return you a Request Token.
If you use the HMAC-SHA1 method, the Consumer Secret and Token Secret will be used to sign your requests. These two secret parameters are known both to your application, and Google, and act like a secret key in a symmetric encryption algorithm.
In order to use RSA-SHA1 method however, you should have already uploaded your Public Key to the server (Google Server) during the registration process of your application. After that, you will use your Private Key to sign your OAuth requests. In your case, since you have not registered your application, Google is not aware of your Public Key, and therefore using RSA-SHA1 method to sign your requests with an unknown Private Key is of no use.
The first method is usually preferred over the RSA-SHA1 method for performance reasons. (symmetric encryption is faster than asymmetric one)
So this is the way I could successfully get a Request Token in the OAuth Playground:
Set 'oauth_consumer_key' to anonymous (unless you have
registered your application and have a real Consumer Key)
Set 'consumer secret' to anonymous (unless you have registered your
application and have a real Consumer Secret)
Choose https://www.google.com/analytics/feeds/ as the scope of request.
Press 'Request token' button
Result:
GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="116d4df85e784f51cf40f0bc3a967883", oauth_timestamp="1322083727", oauth_consumer_key="anonymous", oauth_callback="http%3A%2F%2Fwww.googlecodesamples.com%2Foauth_playground%2Findex.php", oauth_signature_method="HMAC-SHA1", oauth_signature="vVxpbtHlTR%2BJ1yT%2BYS1HOvRzhOs%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 23 Nov 2011 21:28:47 GMT
Expires: Wed, 23 Nov 2011 21:28:47 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 118
Server: GSE
oauth_token=4%2F7E_YtZFHuKFPbuAGuCzyj2AsHcha&oauth_token_secret=NHZBJCj2BPxR2HQZhCTwdq2A&oauth_callback_confirmed=true
Now that you have acquired oauth_token and oauth_token_secret, you can press Authorize button. This will redirect you to the login page of Google (if you are not signed in) and then to the page you grant access to the application. By granting access, you will get back to the callback url in the playground with a verifier code. Pressing 'Access token' button, will get you the access token:
GET /accounts/OAuthGetAccessToken HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="c222a88cc9f027430b239f4cc6f3f154", oauth_timestamp="1322084080", oauth_consumer_key="anonymous", oauth_verifier="TA6vWcDJC51A9YwMNfmUzmUQ", oauth_token="4%2F7E_YtZFHuKFPbuAGuCzyj2AsHcha", oauth_signature_method="HMAC-SHA1", oauth_signature="q9M%2BjeHNxB2ONPd1DPMn6GriUC8%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 23 Nov 2011 21:34:40 GMT
Expires: Wed, 23 Nov 2011 21:34:40 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 103
Server: GSE
oauth_token=1%2Fxy49iwSQEcqSDbo3cKO-UuPLqvt9qKFit9vaLqR6P-M&oauth_token_secret=IJWB1CVSQfYJJPrf9jXv6SS8
*Note: One time, I got the signature_invalid response too, even though I had entered anonymous credentials. But after trying again and pressing 'Request token' button one or two more times I made it. I think this should be due to how nonce and timestamp parameters work to sign the request. This could be the cause of problem. Read this article for more info.
Further reading:
Managing the OAuth key and secret
Registration for Web-Based Applications
Googler here. Haven't fielded OAuth 1 questions in a long time because everyone's moving to OAuth 2 (and you should too) but I'll try to go through the usual suspects on invalid signature errors:
Your server's clock may be wrong. There's a timestamp component and it needs to match ours pretty closely. Try updating your clock against one of the major reference time servers. This happens, but it's an uncommon issue.
Depending on how low-level the OAuth client you're using is, you may have forgotten to supply part of the key used to generate the signature. The key has two pieces, colon-separated, IIRC. In some parts of the protocol, only one half is needed, but for other parts of the protocol, you need both. I've seen cases where someone kept supplying only the first half when both were needed. Actually, I think I made this mistake myself a couple times.
Probably not an issue in your case, because you haven't even gotten past the request token, but OAuth 1 requires you to sign the URI query parameters. Failure to do this will cause the signature base strings to mismatch, thus causing the signature to be invalid.
By far the most common issue is improper encoding. This usually gets expressed as signatures that work sometimes, but fail other times, because sometimes you get lucky and nothing needs to get encoded. I suspect this is what #Meysam ran into based on his comment that he pressed the button a few more times and suddenly it worked.
By the way, if you have to use OAuth 1, you should be using HMAC-SHA1 unless you've got a really good reason to do RSA-SHA1.
I've got a really strange issue in MVC/IE8 and I was wondering if anyone had seen anything like it. I've got a URL that returns an excel spreadsheet in the form http://application.mycompany/Controller.aspx/Action/ID1/ID2 (I am using the .aspx in the route due to the version of IIS). This opens from a page with the application, fine. I also have e-mails with HTML bodies that get sent around that have links in them and all the links open fine apart from this one - it gives an error saying "Cannot download ID2 from application.mycompany, IE was unable to open the site". I've checked the HTML in the e-mail and the link location on the page that works and they are the same. If I type the exact link text (or copy and paste it from the e-mail) into the IE address bar it again fails, but then if I click on the same text in the addres bar at the end and hit enter a second time it loads and spits out the file. It seems to work ok pasting it straight into FireFox, but I can't check clicking on the link and loading FF as I'm working remotely and don't have Firefox on my citrix desktop, nor can I find anyone who has it as their default browser (but as it works first time, I would imagine it would be ok).
Has anyone seen this before or got any ideas what might be causing it, please? This issue occurs on more than one machine, so it isn't an odd add-in/setting as far as I can see.
Thanks
MH
----------------------------Update-----------------------
I've used Fiddler to see what's going on and the response to both requests is identical, apart from the timestamp.
Failed response:-
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/vnd.ms-excel; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
content-disposition: attachment;filename=Filename.xls
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 20 Dec 2010 10:31:52 GMT
Content-Length: 2354
<style type"text/css">.text { mso-number-format:\#; } .TableHead { background-color: #BDBDBD; } </style>
....confidential file content removed
Successful response:-
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/vnd.ms-excel; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
content-disposition: attachment;filename=Filename.xls
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 20 Dec 2010 10:32:18 GMT
Content-Length: 2354
<style type"text/css">.text { mso-number-format:\#; } .TableHead { background-color: #BDBDBD; } </style>
and just to reiterate, the only thing I do to generate the second request is to click on the URL text in the address bar that generated the first request and hit enter.
The error I get is ""Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later."
To quote the similar discussion on the Sitepoint forums.
It's the caching, if you select
no-cache IE can't find the file to
save it, but if you allow caching it
works. Annoying as the same file can
be downloaded at different times and
may well be different if things have
changed, so caching is a little
dangerous (I'll have to suffix the
filename with a timestamp to avoid
this, I think).
http://support.microsoft.com/kb/316431
so this fixes it
Response.Cache.SetCacheability(HttpCacheability.Private);
but it still doesn't explain why it
sometimes works, esp directly from the
web page link
"This behaviour is by design" -
translation "we can't get this to work
and CBA to get it working" - amazing
how firefox, opera and chrome don't
have this problem......
This kb article might help shed some light:
http://support.microsoft.com/kb/316431
"Web sites that want to allow this type of operation should remove the no-cache header or headers."
I've seen some wierdness around IE + Outlook + mailto links with large numbers of characters. Above 128 characters, mailto links do not work with IE + Outlook.
I would try to decrease the number of characters in your anchor to see if you can get it to be more reliable.