I am currently working on an application that allows reverse geocoding using silverlight + bing maps. The thing is that I want to add a reference to the reverse geocoding service provided in msdn ( http://msdn.microsoft.com/en-us/library/cc879136.aspx) i.e. http:// dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl, but when I try to get a reference in vs2010, I get the following error:
The document at the url http:// dev.virtualearth.net/webservices/v1/metadata/geocodeservice/geocodeservice.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 ''', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.'.
Report from 'DISCO Document' is ''', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.'.
Report from 'WSDL Document' is 'There is an error in XML document (1, 1).'.
'', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.
Metadata contains a reference that cannot be resolved: 'http://dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl'.
Content Type application/soap+xml; charset=utf-8 was not supported by service http: //dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl. The client and service bindings may be mismatched.
The remote server returned an error: (415) Unsupported Media Type.
If the service is defined in the current solution, try building the solution and adding the service reference again.
It is good to mention that I can access the service URL from the browser (with a no style information warning). I am aware that there are other reverse geolocoding services out there, but I am somewhat forced by certain circumstances to use only Microsoft-related components/services. Please help :)
I've just tried the same thing and it seems to work fine for me. I saw an article on the MSDN newsgroups that suggest there may have been a problem at some stage with the references (see a post on Bing Map Route Calculation Service) although it mentions that it was the staging URL's that were causing a problem, not those that you're using (as in the article currently). Other than that, are you using the current RC of VS2010? (on the off chance that there were issues in an earlier version)
Might be worth trying again; I've whipped up a stub application at http://code.google.com/p/bingmapssilverlightapp/downloads/list if it's any use.
Related
I have my website hosted on IIS with window 2016 OS. When I am going to disable the Form Authentication under IIS, it is giving me the following error.
Form Authentication.
Exception from HRESULT: 0xC00CEF03
i had a similar issue but it occurred when i was trying to disable the 'Machine key' - 'automatically generate at runtime' and then Applying the same.
For your error, please verify if the authentication is enabled/disabled for Default Web-site. Change that setting and then try disabling you specific websites status. It should ideally work.
I've seen this error stem from three different controls on the authentication method:
If configuring the authentication method on an application, and the authentication method you're trying to disable is enabled on the containing site.
If configuring the authentication method on a site, and the authentication method you're trying to disable is enabled on the Default Web Site.
If configuring the authentication method that has been defined in a web.config file. You should adjust it in the config file.
0xC00CEF03 error code translates to WR_E_NSPREFIXWITHEMPTYNSURI which refers to “Writer: cannot use prefix with empty namespace URI” (Reference).
This error occurs when there is something wrong with the web.config file. It’s probably corrupted or there are incompatible tags and parameters. As a result of this corruption and incompatibility, IIS is not able to read this file. Therefore, it can’t make a change.
The issue mostly happens after migration because a piece of configuration that works in the older version of IIS (and .NET Framework) probably became unsupported in the newer version.
The shortest way of finding what part of the web.config is causing the issue is to remove sections one by one and test. High-level steps:
Remove a section from the bottom of the file (Let’s say you removed system.serviceModel section)
If the issue goes away, add the section back and start removing the subsections of it one by one. (For example, ws2007HttpBinding subsection in system.serviceModel section)
If the issue goes away again, bring the subsection back and go through each lines. Prefixes like wsid:, asm:, and trust: are the most common causes of this issue
Source: 0xC00CEF03 error (Cannot use prefix with empty namespace URI)
Recently got a new machine to setup and run previously working code with classic ASP, on IIS 7.5 with SQL Server 2008 R2 on a 64-bit Windows 7 Enterprize (local development environment). Local regional settings : American.
Problem: Identical code works on old machine but all the AJAX code is broken on the new machine with the following message
An error has occured. (parsererror / SyntaxError: JSON.parse: expected ',' or ']' after array element at line x column xxx of the JSON data)
I can see for a particular page where data should be picked up for a particular colum of JSON response, that picks up wrong colum (could be due to COMMA separation issue(!)). On the pages data is displayed for a particular month of the Year. That is picked up from browser with Request.Form("time") piece of code.
Question: Is it some kind of localization issue? If yes, then where? On the Web server or SQL server. Don't seem to understand where to start finding the issue.
Code can be viewed here.
Apparently it was an IIS setting issue for ASP with LCID attribute that defines how dates, times, and currencies are formatted. Before the fix the web server returned float values with COMMA instead of Decimal point. Actual code has the meta tag CODEPAGE="65001", that is the Windows code page identifier for UTF-8, which didn't match with the encoding is being received. The issue is that the value should match the actual encoding sent.
Possible Fix: Setting Locale ID = 127 on IIS Manager->Site->ASP->Locale ID Solved the problem.
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
On my production ASP.NET MVC 3 site, I've been noticing the occasional "A potentially dangerous Request.Path value was detected from the client (%)." unhandled exception in the Windows application log.
While these can be perfectly valid under regular site usage (ie/ random web bots), a number of the requests appear to be from valid, local ISP users.
In the exception's request details, the Request URL is different than the Request path:
Request URL: http://www.somesite.com/Images/Image With Space.jpg
Request path: /Images/Imagehttp://www.somesite.com/Images/Image With Space.jpgWithhttp://www.somesite.com/Images/Image With Space.jpgSpace.jpg
Notice that in the "request path", any place there is a "space" in the path is replaced with an exact copy of the request url!
Within the site, the actual link looks like this:
<img src="/Images/Image%20With%20Space.jpg" />
Any idea what might be causing this? I tried to look at the documentation for Request.Path and Request.Url, but I can't figure out why they would be different. Hitting the Request URL directly brings up the resource correctly.
Update: I managed to get a trace of one of the malfunctioning requests by using IIS 7.0's Failed Request Tracing feature:
Referer: Google search
User-Agent: Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
RequestURL: http://www.somesite.com:80/Images/Image%20With%20Space.jpg
Typing the URL manually into my iOS 5.1.1 brings up the image correctly. Searching for the image in Google Images brings up the image correctly. Still no successful reproduction.
Partway down the trace I see:
MODULE_SET_RESPONSE_ERROR_STATUS Warning. ModuleName="RequestFilteringModule", Notification="BEGIN_REQUEST", HttpStatus="404", HttpReason="Not Found", HttpSubStatus="11",
According to IIS' documentation, 404.11 from the Request Filtering module is a "double encoding" error in the URL. Experimenting a bit, if I purposefully create a double encoded url such as http://www.somesite.com/Images/Image%2520With%2520Space.jpg I get the exact error in the event log, complete with malformed Request Path.
The malformed Request Path in the event log error appears to be a bug in ASP.NET 4.0.
It doesn't, however, explain why I'm getting the error in the first place. I checked a large number of failed request logs - the only common factor is that they're all using AppleWebKit. Could it be a bug in Safari?
The httpRuntime section of the Web.Config can be modified to adjust the URL validation. ASP MVC projects are usually running in the validation mode 2.0 and the default invalid characters (separated by commas) are listed below.
<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="<,>,*,%,:,&,\" />
As you can see the % sign is considered invalid. A space can be encoded to %20 causing the validation error. You can just add the requestPathInvalidCharacters attribute to the httpRuntime section in your Web.Config file and copy the values I listed below except for the "%," part.
Scott Hanselman has a blog post about this issue:
http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx
I can't help thinking that - given the restricted user-agent - this might represent incorrect handling of the URL by that browser on IOS 5.1.1. I don't personally own such a device so I can't test this - but it would be interesting to investigate how it behaves with a url that actually has spaces in it instead.
I have a feeling that it's seeing the %20 in the url from the page source and double-encoding it, thinking it's being helpful. The problem there being that IIS will decode it back (before ASP.net kicks in) and throw it's rattle out of it's pram because now it sees a literal %20 instead of a space.
I personally don't recommend modifying your servers' security settings; however it would be the easiest solution so I dare say that's what you will do.
Rather, I think if you can confirm this 'bug' (I'm already on the road, finding a safe hiding place from Apple's lawyers), find a format that works for this device; or take all the spaces out of your resource urls. A - is the best alternative.
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