"Your API key is not valid on this domain" when calling Disqus from WP7 - silverlight

I'm trying to access the REST Disqus API using the following url:
http://disqus.com/api/3.0/threads/listPosts.json
?api_key=myKey
&forum=myForum
&thread:ident=myIdent
When I go to the url in Chrome, it works fine. When I try to download it in WebClient, I have difficulty:
WebClient data = new WebClient();
Uri queryUri = new Uri(DisqusQuery + ident, UriKind.Absolute);
data.DownloadStringCompleted += new DownloadStringCompletedEventHandler(onDownloadCompleted);
data.DownloadStringAsync(queryUri);
The DownloadStringCompletedEventArgs contain the following error:
{"The remote server returned an error: NotFound."}
at System.Net.Browser.ClientHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.ClientHttpWebRequest.<>c__DisplayClass2.<EndGetResponse>b__1(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass4.<BeginOnUI>b__1(Object sendState)
at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethoThe thread '<No Name>' (0xfc10086) has exited with code 0 (0x0).
What could I be doing wrong?
Update: Looking in Fiddler shows that the response is this:
HTTP/1.1 400 BAD REQUEST
Date: Sun, 28 Aug 2011 14:51:39 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Cookie,Accept-Encoding
p3p: CP="DSP IDC CUR ADM DELi STP NAV COM UNI INT PHY DEM"
Content-Length: 68
Connection: close
Content-Type: application/json
X-Pad: avoid browser bug
{"code": 11, "response": "Your API key is not valid on this domain"}
Here is the response when the request is from Chrome Incognito (not logged in to disqus):
HTTP/1.1 200 OK
Date: Mon, 29 Aug 2011 17:00:29 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Ratelimit-Remaining: 1000
Content-Encoding: gzip
Vary: Cookie,Accept-Encoding
X-Ratelimit-Limit: 1000
p3p: CP="DSP IDC CUR ADM DELi STP NAV COM UNI INT PHY DEM"
X-Ratelimit-Reset: 1314640800
Content-Length: 3120
Connection: close
Content-Type: application/json
/* expected JSON response */
Update 2: The above error is using my public key. Using the secret key results in:
HTTP/1.1 403 FORBIDDEN
Date: Sun, 28 Aug 2011 20:40:32 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Cookie,Accept-Encoding
p3p: CP="DSP IDC CUR ADM DELi STP NAV COM UNI INT PHY DEM"
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json
2a
{"code": 5, "response": "Invalid API key"}
0

FIX:
Add something similar to the following line to your HttpRequest:
client.Headers[HttpRequestHeader.Referer] = "http://mywebsite.com";
Longer Description:
The problem has to do with the way Windows Phone is setting the HTTP Referer header.
When running the successful request from the browser address bar, Fiddler showed me this:
GET /api/3.0/forums/listPosts.json?forum=disqus&api_key=jRml... HTTP/1.1
Accept: */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate, peerdist
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; Zune 4.7; InfoPath.3; MS-RTC LM 8)
Connection: Keep-Alive
Host: disqus.com
Cookie: disqus_unique=...
X-P2P-PeerDist: Version=1.0
When I examined the request sent by Silverlight in Fiddler, I saw the following:
GET /api/3.0/forums/listPosts.json?forum=disqus&api_key=jRml... HTTP/1.1
Accept: */*
Referer: file:///Applications/Install/9036AAF3-F213-4CFB-B57E-576A05E1896D/Install/
Accept-Encoding: identity
User-Agent: NativeHost
Host: disqus.com
Connection: Keep-Alive
By removing the Referer header and resubmitting via Fiddler, the query worked as I expected! So... all you need to do is manually set the HTTP Referer header to something you control (rather than letting Silverlight do it for you) and you should be good to go.
Oh - and also make sure you're using your public key, not the secret key.
/ck

Looks like the browser is getting additional info like username or something: X-User: anon:182210122933. This is missing when WebClient gets its response back. I guess this has something todo with the fact that you are logged in in the browser or that you have a typo in your api key.
Another interesting pointroject for you would be a library like http://disqussharp.codeplex.com/ which handles authentication most of the time.
Good luck!

Related

React Axios is returning error 500, Laravel BE + Apache, no issue on direct API call via PostMan

There are a lot of issues like this, but I don't see any resolutions.
I had a VPS.
I set up my React build files on public_html root.
I have my Laravel setup on the same folder: public_html/casino/server/public
I am using Axios to process the request to Laravel endpoints.
PHP-FPM 7.4
Apache 2.4
Laravel 5.8
This is the Request Header:
POST /casino/server/public/sysman/login HTTP/1.1
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 154
Content-Type: application/json;charset=UTF-8
Cookie: CookieInfoScript=1
Host: ***.com
Origin: https://***.com
Referer: https://***.com/login
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
sec-ch-ua: "Google Chrome";v="105", "Not)A;Brand";v="8", "Chromium";v="105"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
The Response Header: (as you can see content-length is 0)
HTTP/1.1 500 Internal Server Error
Date: Mon, 05 Sep 2022 02:50:18 GMT
Server: Apache
Access-Control-Allow-Origin: https://***.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: x-xsrf-token, x-requested-with, Content-Type, origin, authorization, accept, client-security-token
Access-Control-Expose-Headers: Content-Security-Policy, Location
Access-Control-Max-Age: 600
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: close
To add GET Requests are being processed just fine.
I can also process the login request via Postman.
But of some reasons, not when coming from the React App.
No errors on BE, everything is running as expected.
Banging my head on this one for a few days already.
Can't seem to figure it all out.
Not much action on htaccess side.
The root online contains redirect to /login page.
Laravel public htaccess only contains the usual laravel stuff.
Apache Error Log:
[Sun Sep 04 22:50:18.527744 2022] [proxy_fcgi:error] [pid 21267:tid 47190394283776] [client 103.177.208.118:58353] malformed header from script 'index.php': Bad header: \x1f\x8b\b, referer: https://***.com/login [Sun Sep 04 22:50:18.527836 2022] [proxy_fcgi:error] [pid 21267:tid 47190394283776] [client 103.177.208.118:58353] AH01070: Error parsing script headers, referer: https://***.com/login [Sun Sep 04 22:50:18.527858 2022] [proxy_fcgi:error] [pid 21267:tid 47190394283776] (22)Invalid argument: [client 103.177.208.118:58353] AH01075: Error dispatching request to : , referer: https://***.com/login
Lastly, when running php artisan optimize, I am seeing Content type being outputted on console, can this be the issue?
[

Cross-origin POST request not working even though it is allowed (GET works)

I have a weird problem. I am testing this using Angular.js 1.2.15.
I want to send a POST request to a RESTful API backend on another domain (and I want to use $http directly, not $resource).
var mapData = {
'some': 'keys',
'other': 'keys'
}
$http.post(endPoint, mapData);
This is what happens: An OPTIONS request is sent first, with the following request headers:
OPTIONS /api/maps HTTP/1.1
Host: myhost.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://0.0.0.0:9000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/36.0.1985.125 Chrome/36.0.1985.125 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://0.0.0.0:9000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
The response clearly shows that requests from other origins and with every method are allowed:
HTTP/1.1 204 No content
Server: Varnish
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Access-Control-Max-Age: 0
Content-Type: text/plain charset=UTF-8
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:50:16 GMT
X-Varnish: 166874803
Age: 0
Via: 1.1 varnish
Connection: close
Cache-Control: max-age=0, private
X-Varnish-Cache: MISS
But then, the POST request is not even sent by the browser (Chromium 36), i.e. it does not show a POST request in the network tab of the dev console.
Instead, the following is shown in the console:
XMLHttpRequest cannot load http://myhost.com/api/maps. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://0.0.0.0:9000' is therefore not allowed access.
Now, what is totally weird: GET requests to the same API work, and are not preceded by an OPTIONS request (or maybe it is not shown in the network tab).
HTTP/1.1 304 Not Modified
Server: nginx/1.4.7
Content-Type: application/json; charset=utf-8
Status: 200 OK
X-UA-Compatible: IE=Edge,chrome=1
ETag: "baca3b7547fed3377088eb81fe083ff8"
X-Request-Id: b2552dc4fdef2541c841e3d5e12d337e
X-Runtime: 0.110003
X-Rack-Cache: miss
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:54:31 GMT
X-Varnish: 166874831 166874142
Age: 6223
Via: 1.1 varnish
Connection: keep-alive
Cache-Control: max-age=0, private
X-Varnish-Cache: HIT
I really have no clue what the problem could be here. Is it Angular's implementation? Or is it a misconfiguration on the server? The guys responsible for the API told me it usually works with all their web apps.
I understand that this is a CORS problem and I am by no means an expert when it comes to that, but hey, Access-Control-Allow-Origin: * should do the trick, shouldn't it?
UPDATE: It works when using plain XMLHttpRequest:
var http = new XMLHttpRequest();
var url = endPoint;
var params = JSON.stringify(mapData);
http.open("POST", url, true);
I get a 200 back.
What is the matter here?
Nginx has to be compiled with http://nginx.org/en/docs/http/ngx_http_headers_module.html for Access-Control-Allow-Origin: * to work. Do you have this module installed?
location / {
add_header Access-Control-Allow-Origin *;
}

Chrome failing to decompress gzip, content length

My Silverlight 4 app downloads quite a bit of data from the server through a WCF service, so I implemented gzip compression using the technique described here: http://forums.infragistics.com/blogs/anton_staykov/archive/2010/08/24/silverlight-wcf-service-compression-azure.aspx
In short, I extended the WCF gzip encoder sample ( http://msdn.microsoft.com/en-us/library/ms751458.aspx ) to work with Silverlight. The server compresses the WCF responses with gzip, and on the client side, the browser HTTP stack decompresses the response automatically before it gets to Silverlight. All is well, and the compression works very nicely in IE.
Testing the same thing in Chrome, however, leads to this..
System.Xml.XmlException: The input source is not correctly formatted.
at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
at System.Xml.XmlBufferReader.ReadValue(XmlBinaryNodeType nodeType, ValueHandle value)
at System.Xml.XmlBinaryReader.ReadNode()
at System.Xml.XmlBinaryReader.Read()
at System.Xml.XmlBaseReader.ReadEndElement()
at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader, EnvelopeVersion envelopeVersion)
at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader)
at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeBodyContents(Message message, Object[] parameters, Boolean isRequest)
at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeReply(Message message, Object[] parameters)
at System.ServiceModel.Dispatcher.ProxyOperationRuntime.AfterReply(ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.RealTimeDataServiceClientChannel.EndGetNowTime(IAsyncResult result)
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataService.EndGetNowTime(IAsyncResult result)
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.OnEndGetNowTime(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)
I've checked out the requests + responses from both browsers in Fiddler, and they are very nearly identical, with one crucial difference -- Content-Length for the Response is set incorrectly for Chrome. I'm sure this is why the XML SOAP is failing to parse.. Chrome is only decompressing part of the content due to the incorrect content length. What gives? Why would my WCF service send back the wrong Content Length for Chrome but not IE?? I change nothing but the browser - code is identical, and the response bodies are identical (Fiddler can decompress both fine). Anyone have a clue why this is happening?
Fiddler:
~~ Internet Explorer 9 ~~
Request
POST http://127.0.0.1:84/services/RealTimeDataService.svc/binary HTTP/1.1
Accept: */*
Referer: http://127.0.0.1:84/ClientBin/Silverlight4.View.xap
Accept-Language: en-US
Content-Length: 207
Content-Type: application/soap+msbin1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: 127.0.0.1:84
Connection: Keep-Alive
Pragma: no-cache
Response
HTTP/1.1 200 OK
Cache-Control: private,no-cache
Pragma: no-cache
Content-Length: 512
Content-Type: application/soap+msbin1
Content-Encoding: gzip
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 08 Jul 2011 16:18:09 GMT
~~ Chrome ~~
Request
POST http://127.0.0.1:84/services/RealTimeDataService.svc/binary HTTP/1.1
Host: 127.0.0.1:84
Connection: keep-alive
Referer: http://127.0.0.1:84/ClientBin/Silverlight4.View.xap
Content-Length: 207
Origin: http://127.0.0.1:84
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30
content-type: application/soap+msbin1
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK
Cache-Control: private,no-cache
Pragma: no-cache
Content-Length: 149
Content-Type: application/soap+msbin1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 08 Jul 2011 16:05:43 GMT
Content-Encoding: gzip
I ended up implementing a workaround to compress the WCF service response and decompress it on the Silverlight library. I used SharpZipLib:
For the web project: http://sharpdevelop.net/OpenSource/SharpZipLib/
Silverlight version: http://slsharpziplib.codeplex.com/
In my WCF service, I have both compressed and uncompressed methods.. the compressed methods return byte[] which gets decoded on the Silverlight side. I expose the uncompressed methods, which return the raw objects, because I need the classes of these objects to be exposed to the client side. (if anyone has a better idea of how to do this, I'd love to hear it)
Make you don't set the content-encoding HTTP header for these responses, as they are handled by the SL client app, not by the browser.
I was never able to figure out why Chrome wouldn't decompress my WCF response automatically, but this workaround achieves the same result.

Firefox 3.6.13 configuration for spnego authentification

I'd like to access to a web application which requires spnego authentification.
This application is running on a network on which i'm connected by VPN connection. Proxy not used.
It works fine under IE6/7/8, Chrome but not firefox 3.6.13
The matter on firefox is: I don't have the prompt message box to enter username and password
To configure my FF, i applied the following instructions, adding the domain name to the trusted and delegation uris fields.
Trying to access to the application, i get the following error message:
A browser did not respond to authentication challenge sent by a server.
Most probably your browser is not configured properly to handle SPNEGO authentication challenge or does not support SPNEGO.
Please, contact your System Administrator to deal with the problem.
Using TCPMon to get an overview of the informations received:
GET /AppName HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/ HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/logon HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
Location: http://app.domain:8182/AppName/
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
0
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0
Location: http://app.domain:8182/AppName/logon
Content-Type: text/html
Content-Length: 0
Date: Tue, 14 Dec 2010 16:16:28 GMT
HTTP/1.1 401 Non-Autorisé
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
WWW-Authenticate: Negotiate
Connection: close
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
4b9
I've checked for the other browsers and i got the same informations.
Do someone have an idea why FF can't interprete it, prompt a dialog box or enter the application ?
Thanks in advance for any help.
Best regards.

SharePoint 2010 / IIS 7.5 Byte-Range Request Responds With Entire File

I'm having problems getting SharePoint 2010/IIS 7.5 to respect byte-range requests. I'm developing a SharePoint 2010 Web Part using Silverlight, and am trying to retrieve part of a document stored inside SharePoint.
When I request a byte range of a file in SharePoint, the server responds with the entire file. However, if I request the same byte range from a file sitting on an Apache server, everything works as expected. Below are the http headers observed with Fiddler.
Any help would be really appreciated! Thanks.
Sent:
GET http://example.com/file.abc HTTP/1.1
Accept: */*
Accept-Language: en-US
Referer: http://example.com/index.html
Accept-Encoding: identity
Range: bytes=1061285-1064594
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4
Host: example.com
Connection: Keep-Alive
SharePoint also takes login credentials:
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Received from Apache:
HTTP/1.1 206 Partial Content
Date: Wed, 25 Aug 2010 22:40:34 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 20 Aug 2010 23:27:18 GMT
ETag: "b68e346-103ea9-a3c20180"
Accept-Ranges: bytes
Content-Length: 3310
Vary: User-Agent
Content-Range: bytes 1061285-1064594/1064617
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: application/x-zip
Received from SharePoint 2010 / IIS 7.5
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Content-Length: 1064617
Content-Type: application/octet-stream
Expires: Tue, 10 Aug 2010 22:40:56 GMT
Last-Modified: Wed, 25 Aug 2010 19:28:39 GMT
ETag: "{5A1DF927-D8CD-4BC0-9590-8188CF777A3D},1"
Server: Microsoft-IIS/7.5
SPRequestGuid: 99799011-5bdc-489f-99fd-d060a56d3ae4
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
X-SharePointHealthScore: 5
ResourceTag: rt:5A1DF927-D8CD-4BC0-9590-8188CF777A3D#00000000001
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename=file.abc
X-Download-Options: noopen
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.4762
Date: Wed, 25 Aug 2010 22:40:56 GMT
The problem is that SharePoint caching is off be default, and needs to be turned on to enable byte-range requests. See Disk-Based Caching for Binary Large Objects.
Note http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2:
"A server MAY ignore the Range header."
Thus whenever you are using a Range header you must be able to handle a 200 response. The fact that your server doesn't appear to support range serving is unfortunate, but conformant.

Resources