Appharbor - Build failure - Either the Signature query string parameter or the Authorization header - appharbor

I have a working ASP. NET Web application on AppHarbor. But since yesterday when we commit changes, we are getting build error as follows.
Could it be related to the code we are deploying?
Code-InvalidArgument-Code
Message-Either the Signature query string parameter or the Authorization header should be specified, not both-Message
ArgumentValue-
00ae7439f3e3d4956d325c6868fe1853b48671a4db49deb209c1ce0691b5dc66c9dcda413d6c1223df705c8b085e088eee552ed255fb60068878d386a150d21bad/008faea860883ff98643593aa166cdf07b19d415bc8abdc1132a2d1ed9f9d7fa4b5dbe316f6bd04eb77d714fd3bfb2e259ac4bdbbcc8e839d3569227c8e51ba83d-ArgumentValue
ArgumentName-Authorization-ArgumentName
RequestId-B2EC5601E4D4C6C8-RequestId
HostId-6ot5sQ9xgCaC6GgipaU5ULqd9TfvF23IH6bcLmc8Wmupe1UP5GeR8vGPws5b71iN-HostId
-Error

Related

Tool to validate a web.config

Is there a tool that I can use to validate my web.config? The reason I ask is that the file appears to be valid XML and IIS is complaining that file is invalid. No explanation or indication as to why.
Thanks in advance.
Edit:
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information:
Module IIS Web Core
Notification Unknown
Handler Not yet determined
Error Code 0x8007000d
Config Error
Config File \?\C:\DignityFiles\Source\simplicity\Simplicity\web.config
Requested URL http://simplicity-local.dignitytest.co.uk:80/
Physical Path
Logon Method Not yet determined
Logon User Not yet determined
Config Source:
-1:
0:
More Information:
This error occurs when there is a problem reading the configuration file for the Web server or Web application. In some cases, the event logs may contain more information about what caused this error.
View more information ยป [This takes you to "https://support.microsoft.com/en-gb/help/942055/-http-error-500-19-error-when-you-open-an-iis-7-0-webpage"]
Link to the web.config (Note: sensitive information has been redacted)
I have (eventually) found the answer: https://stackoverflow.com/a/41267673
Installing the URL rewrite module fixed my issue.
This answer addressses the immediate concern, but if you are looking for a general solution in powershell I have created a function that addresses this.
The full answer is here: how do i validate an IIS web.config in powershell
But the gist of it is you have to find all the "filters" and test each of them individually via Get-WebConfiguration

OWin Startup attribute not found error on Web API REST Request

I have a Web API project along with the built in help website. When I start up the project locally, the help website home page displays no problem. But when I send a REST POST request to an API controller using fiddler, I get the following response.
The following errors occurred while attempting to load the app.
- No assembly found containing an OwinStartupAttribute.
- No assembly found containing a Startup or [AssemblyName].Startup class.
To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config.
To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.
I have tried to solve using the suggestions in the error message but no joy.
It works OK on the test server.
Can anyone suggest why this error is returned only on a REST request and not when the help website starts up and any tips on how to solve?

SOAP WSDL accessible in SoapUI, not in Visual Studio

I'm attempting to integrate a SOAP web service into my C# project via "Add Service Reference," as I have done successfully at least once before. The address works normally in SoapUI, and even entering the address in a browser brings up the WSDL file as expected. But when I enter the address in the Add Service Reference dialog, it results in an error.
The document at the url [redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl was not
recognized as a known document type. The error message from each known type may help you fix the problem:
Report from 'XML Schema' is 'The root element of a W3C XML Schema should be and its namespace should be 'http://www.w3.org/2001/XMLSchema'.'.
Report from 'DISCO Document' is 'Discovery document at the URL [redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl could
not be found.'.
The document format is not recognized.
Report from 'WSDL Document' is 'There is an error in XML document (2, 129).'.
The string 'http ://webservice.uesas._[redacted].webroot' is not a valid Uri value.
Metadata contains a reference that cannot be resolved: '[redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl'.
The content type text/html of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were:
... followed by the first several lines of what is clearly HTML code, instead of WSDL code. So evidently, VS doesn't even SEE the WSDL file, even though SoapUI and any standard browser confirm it's there. Does anyone have any thoughts why this would be?
Add ?WSDL after the endpoint address like: http://localhost:8088/mock_service?WSDL

Web API 404 File or Directory not Found for "root" routes

I am developing a RESTful web api service. It's web api v.1, not v.2. Also I am developing on Visual Studio 2010 SP1. I have installed the MVC 4 for VS2010 SP1.
Please understand and keep in mind that Upgrading to newer versions of VS or Web Api 2 is not an option.
I have the following problem after a Windows Update ocurred.
When I try to use my RESTful api this way....
http://url.com/documents/ (get all the documents) I get the following error...
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Here is the stack trace.
[HttpException]: File does not exist. at System.Web.StaticFileHandler.GetFileInfo(String virtualPathWithPathInfo, String physicalPath, HttpResponse response) at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context, String overrideVirtualPath) at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state) at system.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
If I specify the action name directly, it works. For example...
http://url.com/documents/get (gets all the documents) or
http://url.com/documents/7 (gets document id=7.
It only fails when you call it by its default name. I have already read similar situations here and I have tried to follow their solutions but they are not working for me properly.
Now, I know this is not a "web api routing" issue because I actually get the .net default exception page html markup (I am using Postman to test my webservice). When I force a "routing issue", then I get a JSON error description, which means that the Controller actually got created in the pipeline and returned a response.
Also, I have a custom file (SecurityHandler) that inherits from DelegatingHandler. This file gets executed almost first in the pipeline with each call to the api. Even before the actual Controller. Well, this file is never called when I get the error, which confirms to me that the "webserver" (either VS Development Server or IIS 7) is the one throwing the exception.
I have exhausted every single solution that I have found here. Change my web.config to multiple handlers configurations, re-installed MVC 4 for VS2010, created an entire new project... all these efforts have shown no results whatsoever.
Like I said, this was working perfectly fine until my pc restarted from a Windows Update BUT... why does it fail in the server as well? I did deploy my api to the server after the error started to occur.
Thanks.
The issue is not in Web API (and has nothing to do with it's version or Visual Studio 2010), it's the static file handler trying to serve and failing.
Alternatives:
0. Do you have a documents folder in your site? Get rid of it.
1. Remove the static file handler for directory browsing and re-add it.
2. Use RAMMFAR (less recommended)

Team test: Failing load. Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

The folk in the QA department use visual studio team test (2008 IIRC) to run load tests against our web application.
The latest set of tests have failed on several pages. The error reported is
Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
Searching for this using google yields quite a few results. it would appear that this error message is generated from the .Net framework WebRequest class (i.e. it is not a visual studio specific message). The most useful result is this one, which details my exact problem and how to suppress the error.
But of course, I want to get to the bottom of why this error occurs in the first place. Here are some more facts: -
This error never used to occur when the tests were run against an older version of the web app. The web app. host OS and web server (Win 2003 and IIS 6) are identical in both cases.
Not all the pages generate this error - only some.
The only significant change to these pages (that I can think of) is that they now use some AJAX whereas before they did not (IIRC)
In order to narrow down the problem, I created the simplest page that I could to replicate the problem. Luckily, that was not too hard. I then inspected the bytes in the header using Fiddler but I could not find an occurrence of a CR (0x0D) that was not followed by a LF (0x0A).
The raw HTTP response (as stored from Fiddler by response saving bytes - so its encoding should not have been altered during the save) is here as text if you don't believe me!
So now I am left thinking that the supposed error might be a false alarm. Does anyone else have experience of this/can help shed light?
This is definitely not a false alarm - I've been getting this error in my app a lot while trying to communicate with Facebook API.
I've just stumbled upon this response from Steven Cheng - http://www.velocityreviews.com/forums/t302174-why-do-i-get-the-server-committed-a-protocol-violation.html - and let me quote him:
From your description, you're using
the HttpWebRequest component to send
some http request to some external web
resource in your ASP.NET web
application. However, you're always
getting the "The server committed a
protocol violation.
Section=ResponseStatusLine" error
unless you set the following section
in the web.config file:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
And you're wondering the cause of this behavior, correct?
As for this issue, I've performed some
research on this and found that the
problem is actually caused by the
critical http header
parsing/validating of the
HttpWebRequest component. According to
the Http Specification(http1.1), the
HTTP header keys shoud specifically
not include any spaces in their names.
However, some web servers do not fully
respect standards they're meant to.
Applications running on the Dotnet
framework and making heavy use of http
requests usually use the
httpWebRequest class, which
encapsulates everything a web oriented
developer could dream of. With all the
recently issues related to security,
the "httpWebRequest" class provides a
self protection mechanism preventing
it to accept HTTP answers which not
fully qualify to the specifications.
The common case is having a space in
the "content-length" header key. The
server actually returns a "content
length" key, which, assuming no spaces
are allowed, is considered as an
attack vector (HTTP response split
attack), thus, triggering a "HTTP
protocol violation error" exception.
Will try if this helps right now and post results later

Resources