I'm seeing this HTTP header on some requests made to my server:
X-P2P-PeerDist: Version=1.0
I'm aware of this: http://www.faqs.org/patents/app/20110016220#ixzz3g3X8lSYF, but I would like to know what are the known clients sending that header.
Any idea?
UPDATE: as requested, i'm including the other headers sent with the request (I've obfuscated some private stuff that are related to our customer with ***):
GET http://***.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Connection: Keep-Alive
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.3; .NET4.0C; .NET4.0E)
X-P2P-PeerDist: Version=1.0
UA-CPU: AMD64
Accept-Encoding: gzip, deflate, peerdist
Host: ***.com
Cookie: SMSESSION=***; OrgName=***; authCookie=***; ASP.NET_SessionId=***
Pragma: no-cache
Cache-Control: no-cache
The user agent seems to indicate IE11 (Trident/) in IE7 mode (compatible; MSIE 7.0), but I'm not getting the X-P2P-PeerDist header when I'm using this config, so I don't think it's directly related.
It is one of the headers used in the PeerDist peer content caching protocol. It has never been standardized and are not even registered with the IANA registry for HTTP headers.
It is known to be sent from some recent versions of Internet Explorer, .NET HTTP clients and SilverLight HTTP clients.
I’m relatively certain that this header is send when if the client is configured to use BranchCache and a request is made using WinHTTP. About BranchCache:
To optimize WAN bandwidth, BranchCache copies content from your main office content servers and caches the content at branch office locations, allowing client computers at branch offices to access the content locally rather than over the WAN. (Source).
When testing here locally, a client that has BranchCache enabled sends the X-P2P-PeerDist header, while a brand new client (no BranchCache configured) does not sent it.
The underlying protocol seems for is Peer Content Caching and Retrieval (MS-PCCRTP), as the section Message Syntax from the protocol description defines X-P2P-PeerDist as one of the HTTP header extension it uses.
However, the document BranchCache Deployment Guide for Windows Server 2008 R2 and Windows 7 lists other MS-PCCx protocols but not MS-PCCRTP. So I don't have an external evidence that this header is caused by a BranchCache enabled client.
I have seen this in IE11 + compatibility mode on Windows 7, connected to an intranet application and downloading a docx file. The request only appears when downloading a document. All requests are going through an F5 load balancer. In other non-download requests on the same browser and same application, the X-p2p-peerdist header is missing.
Related
I'm totally new to WIF and to start playing with it a bit I tried the simplest "f5 experience" with an MVC4 application; according to the tutorials I found, which sadly for the most part refer to releases before .net 4.5, I should just create an MVC app, configure it with the identity and access tool and hit f5 to get up and running with local STS. Yet, I'm probably missing something obvious because when I try to access a restricted page I always end bumped back to the homepage.
Here is what I did, you can easily repro the issue with these steps (VS2012 in Win8 with WIF SDK; ensure to launch VS with admin rights):
create a new ASP.NET MVC4 Internet application. Set its port to 7777 (just picking the port number used in most code samples for the sake of commodity).
update all the NuGet packages (this is optional).
right click the solution, choose identity and access and set the IP=local STS, then click OK. Then reopen the identity and access popup, and choose generate a controller, then click OK.
add an [Authorize] attribute to the About action of the Home controller.
hit F5 and click the About link. As expected, the login view appears, prompting me to login: the only option is of course localSTS. When I click it, I am returned to the homepage and no authentication occurs. I can repeat the process, but nothing changes, so I can never access the secured About page.
The link underlying the localSTS anchor is:
http://localhost:14743/wsFederationSTS/Issue?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z
AFAIK, its parameters look OK.
If I examine the network traffic, I cannot see any relevant item (if I understand well, I would expect a response setting some cookies for the current session, representing the IClaimsPrincipal).
(BTW, by looking at the web.config, I can see that in modules WSFederationAuthenticationModule is referenced from System.Identity.Services, which is NOT included in the solution after configuring Identity and access; I suppose this is a bug in the tool. Anyway I added a reference to it, but nothing changed.)
Update
Thank you for the reply! If I examine the traffic, here are the relevant GET/POSTs. I get no cookie. I tried recreating the whole test solution, even skipping step #2 above to keep it minimal, but nothing changed.
As for your suggestion #2, I tried to add in global asax:
FederatedAuthentication.WSFederationAuthenticationModule.SecurityTokenValidated
+= (sender, e) => FederatedAuthentication.SessionAuthenticationModule.IsReferenceMode = true;
but the SessionAuthenticationModule is null at the time this code executes and thus a corresponding exception is thrown. I cannot find up-to-date code samples or articles about this, yet WIF seems a very promising tech; I'd like it to be easy for security newbies like me; my main purpose is applying it to a site providing both MVC controllers and WebApi controllers, to a wide range of consumers (JS code, mobile apps, WinRT apps, the site pages themselves...). Any suggestion?
(1) a GET which gets 307, temporary redirect
GET /wsFederationSTS/Issue?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z HTTP/1.1
Host: localhost:14743
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Referer: http://localhost:7777/HrdAuthentication/Login?ReturnUrl=%2fHome%2fAbout
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
Cookie:
(2) GET with signin request:
GET /wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z HTTP/1.1
Host: localhost:14743
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Referer: http://localhost:7777/HrdAuthentication/Login?ReturnUrl=%2fHome%2fAbout
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
Cookie:
(3) a POST to the homepage: the respone is of course the homepage content; no cookies set.
POST / HTTP/1.1
Host: localhost:7777
Connection: keep-alive
Content-Length: 7063
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://localhost:14743
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:14743/wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z
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
Cookie:
A working variation
I found a way for letting it work, maybe this can be useful to someone else: if you follow the above procedure without changing from the local IIS server to the VS development server, it seems it's working and I'm still redirected to the Home page (I wonder why:), but as an authenticated user; at this point, I can click the About link again to effectively enter the page.
I reproduce your steps and everything worked. Chrome debugger show that you must have two steps:
GET http://localhost:12263/wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a54306%2f&wctx=rm%3d0%26id%3dc6e46b99-417b-49b6-96a0-40efcead898f%26ru%3dhttp%253a%252f%252flocalhost%253a54306%252f&wct=2013-03-10T18%3a14%3a19Z
POST http://localhost:54306/ with wa:wsignin1.0 and wresult:trust:RequestSecurityTokenResponseCollection
Result of POST is Set-Cookie named FedAuth and FedAuth1. Cookie is split because of cookie size limit.
Please check this in debugger.
p.s. Once i saw a same behavior - cookie is not set normally. Problem was in cookie size and solved by switching to ReferenceMode. Don't forget to to register it in Application_Start:
FederatedAuthentication.WSFederationAuthenticationModule.SessionSecurityTokenCreated
+= this.WSFederationAuthenticationModule_SessionSecurityTokenCreated;
I'm currently trying to connect to a webservice placed on https://xxx.xxx.xx/myapp
It has anonymous access and SSL enabled for testing purposes atm.
While trying to connect from the 3G network, i get Status 403: Access denied. You do not have permission to view this directory or page using the credentials that you supplied.
I get these headers while trying to connect to the webservice locally:
Headers
Request URL:https://xxx.xxx.xx/myapp
Request Method:GET
Status Code:200 OK
Request Headers
GET /myapp/ HTTP/1.1
Host: xxx.xxx.xxx
Connection: keep-alive
Authorization: Basic amViZTAyOlE3ZSVNNHNB
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response Headers
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 16 Feb 2012 12:26:13 GMT
Content-Length: 622
But when accessing outside the local area, we get the big ol 403. Which in turn wants credentials to grant the user access to the webservice.
However, i've tried using the ASIHTTPRequest library without success, and that project has been abandoned. And they suggest going back to NSURLConnection.
And i have no clue where to start, not even which direction to take.
-connection:(connection *)connection didRecieveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
The above delegate method of NSURLConnection doesnt even trigger. So i have no idea what so ever how to authenticate myself.
All i get is the parsed results of the xml elements of the 403-page.
I needs dem seriouz helps! plx.
This was all just a major f-up.
The site had ssl required and enabled, and setting ssl required for the virtual directories does some kind of superduper meta-blocking.
So, by disabling ssl required for the virtual directories, it runs over ssl and is not blocking 3G access..
I am facing a problem of moving 4+GB size file between computers. First I couldn't move the file on micro SD card (see my other post)
So now I am trying to upload this file. Exact file size is 4549809009, so when I try to upload it, my upload fails at premature ending of a input file.
Here are headers I get:
POST /webfolder/webapp/Folder/MediaChest HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://myotherhost/webfolder/webapp/Folder/MediaChest
Accept-Language: en-US
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)
Content-Type: multipart/form-data; boundary=---------------------------7db2ce294006e4
Accept-Encoding: gzip, deflate
Host: myotherhost
Content-Length: 254842353
Connection: Keep-Alive
Cache-Control: no-cache
So why content length set as 254842353? IE continues uploading after reaching this size, however the upload receiver thinks that end of stream reached. Where is problem, in the receiver or the sender?
One question I would have is, what is hosting the other site? If it is an Asp.Net site hosted by IIS, you will probably need to make sure that the maxRequestLength property in the web.config is set to handle a POST that big.
See:
Increase file upload size limit in iis6
Greetings,
I create a new project (in VS2010) using;
File -> New Web Site -> .NET Framework 3.5 -> WCF Service
Service works great via Cassini, can view the WSDL metadata with success. Then I attempt to setup the application to be served via IIS. Using a .NET 2.0 application pool with "Integrated" pipeline.
I made sure the svc handler is setup on the application (both managed and script) and ran this command as well:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /r
Then when I attempt to view the service metadata via the IIS service I get this (text from a Fiddler session);
GET http://localhost/WCFService2/Service.svc HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
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
HTTP/1.1 200 OK
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 12 Jan 2011 19:04:43 GMT
Content-Length: 0
I was getting a HTTP Error 500 but I changed the permissions on all the files in the folder to "EveryOne" and "full" - just to remove any security issues. Its after this action that the error 500 stopped but the empty content started.
I am using Windows 7 64 bit, VS2010 and have v2.0, v3.0, v3.5 and v.4.0.30319 frameworks installed. I hoped that it would work as simple as this screencast, silly me.
Any suggestions?
Try enabling static content support from "Windows features on or off", this is most likely what is causing the problem.
If the "Static Content" is not enabled the IIS will return a response with Content-Length = 0
Go to Control Panel >>
Programs And Features >>
Turn Windows features on or off >>
Internet Information Services >>
World Wide Web Services >>
Common HTTP Features >>check Static Content.
I've been searching for a solution on the internet for this, and can not find it anywhere.
I've setup a simple POST request through Fiddler for an ASP page on my local machine:
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/x-shockwave-flash
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727)
Host: localhost
Connection: Keep-Alive
Authorization: Basic xW91bsdtcyNqYTpfs8Jkb4ql
Content-Length: 9
asdfdfdsf
The ASP page contains the following line:
Response.Write(Request.ServerVariables("HTTP_Authorization"))
Instead of writing out "Basic .....", it doesn't write anything at all. If I change "HTTP_Authorization" to any of the other headers (HTTP_Content_Length), I can pull in their values.
Is there a reason ASP is refusing to let me see that specific header?
Thanks!
Apparently it was being removed by the server's windows auth
I unchecked "Integrated Windows authentication" and the header started showing up correctly