I have a WCF service that has webHttpBinding and has enableWebScript turned on in it's endpoint behavior configuration.
The response from the service looks something like this
HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 20:09:02 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 25
{"d":{"__type":"SOMETYPE", ... }}
Its using HTTP 1.1 and so there are the standard headers. The contentType is set to be applciation/json which also makes sense. In the message body (the JSON part), everything is enclosed in an envelope titled "d".
What is that? Who defines that protocol? Is it something specific to WCF?
I couldn't find that defined in any of the protocols involved or the definition of the "application/json" contentType.
Thanks
That is ASP.NET AJAX specific and is caused by applying the WebScriptEnablingBehavior (enableWebScript in config) to your endpoint. The wrapper is required on both input and output and there are also special behaviors added around exception handling.
If you want "pure" JSON, you should remove the WebScriptEnablingBehavior and just use WebHttpBehavior (webHttp in config). Then just make sure you explicitly set the Request/ResponseFormat properties on your WebGet/InvokeAttributes.
Related
I'm trying to implement a UI5 service using an OData v4 backend.
In general my bindings seem to work, however, there seems to be a problem parsing the headers of the batch requests. Parsing the batch parts by skipping the code in the debugger works fine.
In the console I get the following error:
2022-10-11 13:14:09.584899 $batch failed - Error: Expected 'OData-Version' header with value '4.0' but received value 'null' in response for http://localhost:8080/odata/$batch
at h.doCheckVersionHeader (http://localhost:1337/resources/sap/ui/core/library-preload.js:4753:314)
at Object.<anonymous> (http://localhost:1337/resources/sap/ui/core/library-preload.js:4786:415)
at Object.<anonymous> (http://localhost:1337/resources/sap-ui-core.js:2099:9272)
at p (http://localhost:1337/resources/sap-ui-core.js:2219:26833)
at Object.fireWith [as resolveWith] (http://localhost:1337/resources/sap-ui-core.js:2219:27676)
at y3 (http://localhost:1337/resources/sap-ui-core.js:2219:84906)
at XMLHttpRequest.<anonymous> (http://localhost:1337/resources/sap-ui-core.js:2219:87536) sap.ui.model.odata.v4.ODataModel`
However, inspecting the headers in the developer tools the OData-Version header seems to be set
HTTP/1.1 202
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
OData-Version: 4.0
Content-Type: multipart/mixed;boundary=batch_63059dbf-3e96-4650-b6b9-c6237b7e3b9e
Content-Length: 3848
Date: Tue, 11 Oct 2022 11:14:06 GMT
Keep-Alive: timeout=60
Connection: keep-alive
In the function h.doCheckVersionHeader only the Content-Type and Content-Length are aviable.
I start my project via ui5 serve and seem to be using version 1.102.1.
Does anyone know how I can get the requests to work?
I have resolved the issue by adding the
Access-Control-Expose-Headers header to the response: https://github.com/SAP/openui5/issues/3613#issuecomment-1274609280
The section "Response Headers" from the documentation topic "Model Instantiation and Data Access" now lists headers that need to be added to the Access-Control-Expose-Headers response header:
The OData model processes some of the response headers, namely:
DataServiceVersion (only when consuming an OData V2 service),
Date,
ETag,
OData-Version,
Preference-Applied,
Retry-After,
SAP-Messages,
X-CSRF-Token.
Some SAP applications will also require the processing of SAP-ContextId, SAP-Err-Id, and SAP-Http-Session-Timeout. When using cross-origin resource sharing (CORS), it is important to add all these headers to the Access-Control-Expose-Headers response header.
Also, make sure that values assigned to the headers are syntactically valid. E.g. no dangling characters: OData-Version: 4.0; → OData-Version: 4.0.
I've build a web api service with basic authentication and using a global DelegatingHandler implementation which I hook up to the web API GlobalConfiguration, in order to extract the username:password credentials from the request and hook an IPrincipal to the HttpContext if the credentials map to a valid user.
I've tested my api thoroughly on localhost and it's working fine, but not quite when hosted on IIS on a VPS.
I've hooked up remote debugging on the VPS in order to inspect whats going on and it turns out that whenever I include the authorization header to my request, the breakpoints I have set on the message handler are not getting hit, meaning that the request does not reach the handler. If I remove the Authorization header from the request, the breakpoint is getting hit and the handler is able to process it.
Since the message handlers are the first that will process the request in the pipeline (from what I know of, correct me if I'm wrong) I guess there must be an IIS or setup issue that I'm not aware of that messes the authentication process.
Fiddler Request Headers
GET http://myip/api/v1/route/parameter HTTP/1.1
Content-Type: application/json; charset=utf-8
Authorization: Basic ZHJpdmVyOjEwMTAyMDAz
Host: myip
Fiddler Response Headers
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Basic realm="myip"
X-Powered-By: ASP.NET
Date: Mon, 22 Aug 2016 15:04:15 GMT
Content-Length: 61
{"Message":"Authorization has been denied for this request."}
What could be possibly be wrong, where should I look at for a solution?
EDIT
Had to disable Basic Authentication from the Authentication menu on the right pane setting for the IIS application.
I am using a SOAP interface that is developed by a 3rd party, but is returning an invalid HTTP header as shown below.
HTTP/1.0 200 OK
Server: SMBDK_1/2.3.0
Date: Thu, 09 Aug 2012 18:59:14 GMT
Connection: close
Content-Length: 670
Content-Type: text/html; charset=ISO-8859-1
Content-Type: text/xml
Expires: Thu, 09 Aug 2012 18:59:14 GMT
Last-Modified: Thu, 09 Aug 2012 18:59:14 GMT
Notice that there are 2 content-type tags. I am using VS2008 for this VB project. I have a service reference for this connection and can send a request and receive a response. I created a CustomTextMessageEncoder using the MSDN samples to read the response for text/html; charset=ISO-8859-1. This is working for single variable returns, but arrays are never read in correctly. They are always empty. I am using a Web Debugging Proxy and can see that the array information is there in the SOAP response, but it is never actually pulled through. I presume this is due to the bad header (?). I tried decoding the message as text/xml; charset=ISO-8859-1 and got the same results... empty array returns.
Does anyone have any advice on how to handle this situation? Do I need to deserialize this message manually or is there a better way?
In the end, these bad headers prevented Visual Studio from ever reading in array's properly.
I wound up having to capture the entire response in an XMl document in memory then open it up and use xmlNodeList to manually read the data from the arrays.
When I try to access WCF client, I get the following error. I was able to access my service using IE and able to reference in VS 2010. My development environment is Windows server 2008. I hosted service in Sharepoint Project server. I am stuck with this error. Please advice.
"The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. "
Here is some data Headers from Fiddler.
GET /_vti_bin/psi/helloservice.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
MicrosoftSharePointTeamServices: 14.0.0.4762
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-SharePointHealthScore: 4
WCF HTTP Activation must be enabled on the server. If the script maps for WCF are not installed you may receive the error.
Context:
BizTalk 2010 trying to call a one way(fire and forget) PeopleSoft service that does not return a response. I have verified that BizTalk 2010 does not support one way services by design. Unable to call one way Peoplesoft service with WCF-Adapter from BizTalk 2010
PeopleSoft team showed me that their asynchronous service returns the following Http status and headers.
HTTP/1.1 200 OK
Date: Thu, 20 Jan 2011 15:31:37 GMT
Content-Length: 0
Content-Type: text/xml; charset=UTF-8
TransactionID: <some GUID>
X-Powered-By: Servlet/2.5 JSP/2.1
However, when I look at the xml returned from a One Way WCF service published by BizTalk 2010 I see this
HTTP/1.1 200 OK
Content-Length: 86
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 20 Jan 2011 15:34:32 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body/></s:Envelope>
Note the empty SOAP message.
Therefore, BizTalk 2010 needs to have a NON-NULL response to be able to call a service.
PeopleSoft service sending back the HTTP status code above IS NOT considered an acknowledgement by BizTalk.
Is that correct?
Thanks.
If a web service does not return a response, it needs to return an HTTP 204 - No Content. I've not tried this in WCF yet, but HTTP honors the no content return code. As for the BizTalk WCF service... not sure why it's not using 204. But since it is using 200, it needs to send something.
It looks like BizTalk 2010 does need to have a NON-NULL response to be able to call a service.
Thanks to Ben for confirmation.
See details here.
What is the nature of the message you send out? You could in theory send a one way HTTP message and correlate on a separate HTTP response port.