OPTIONS on claims-based 2013 site throws Error.aspx when not authenticated

Question

I have a claims-based SharePoint 2013 site that is using a custom logon page and supports multiple authentication methods. In general, things are working as expected. Users can sign-in, access content, get the appropriate role-based claims, and so on.

However, when users connect using Excel for refreshing a query, the login page appears, but it's actually trying to take them to error.aspx. After some investigation, this appears to happen when the user is not yet signed in to the site, so they don't have a FedAuth token - this makes sense somewhat because the point of Excel being able to show the login page is to let the user sign in, right? But I don't see where the error.aspx redirect is coming from, and the ULS log just shows the request for error.aspx, not the reason for the error.

I can reproduce the issue in my development environment, which allows non-SSL, so it's easy to replicate this from a telnet session:

Request (sanitized):

OPTIONS http://fqdn.for.site.here/ HTTP/1.1
Host: fqdn.for.site.here

Reply (sanitized):

HTTP/1.1 403 FORBIDDEN
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.0
X-SharePointHealthScore: 0
SPRequestGuid: 9a3d619c-124b-2027-0000-03f0e96e36ea
request-id: 9a3d619c-124b-2027-0000-03f0e96e36ea
X-Forms_Based_Auth_Required: http://fqdn.for.site.here/_layouts/15/Company/CustomLogon.aspx?ReturnUrl=/_layouts/15/error.aspx
X-Forms_Based_Auth_Return_Url: http://fqdn.for.site.here/_layouts/15/error.aspx
X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4420
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 17 Dec 2013 17:48:58 GMT
Content-Length: 13

403 FORBIDDEN

Besides looking at the ULS log, I've also looked to see if a custom HTTP module is interfering (there is one in place to replace the Access Denied page since 2013's ability to do that "properly" is broken), but bypassing doesn't seem to change anything.

Does anyone have a thought about why my first login is trying to go against error.aspx-, or what I can do to try to track it down further?

Answer 1

Upon a lot more time and investigation it seems this is "normal" behavior. The error doesn't really matter and is thrown away as best I can tell; it might not even be an actual in-real-life error. It looks like the Office clients do some hackish things to do what they do.