I'm working on a small SilverLight application, which uses the WebClient to request a REST service. According to this:
http://msdn.microsoft.com/en-us/library/dd920295(v=vs.95).aspx
no caching should be in place when using the 'Client HTTP' handling....
The REST service I'm calling use ETag, so with no Caching in place, I would not expect, that a second call to my service, would contain the If-None-Match header ??
Also when the REST service returns '304' (NotModified) I still get some data, indicating that the data is returned from the cache....
The REST service also sets the 'Vary' header to 'Accept' (so that the Accept header, should be taken into account when generating the Cache key), but is doesn't seem like this is working....
So I'm a bit confised, whether the caching is there or not.... seems like it's half-ways there...
Can someone clearify??
TIA
Søren
I would suggest not using ETags on a WCF service. In IIS, the service or the directory containing the service needs to include an HTTP response header setting the content to expire immediately so that there is no possibility of caching on the client. This way a call to the service will not result in an HTTP 304 response from the server.
Related
I have an Itinerary that is called from a WCF Web Service (WCFService) through BizTalk. The first thing it does is a transformation, using Maps in WCFService. It then routes the response from the mapping to a Rest Service. I created WS-WebHttp adapter to be used with ESB.
The issue is that when it posts to the web service using HttpRequestMessage object, the message does not contain any content. As a test I also routed the transformation to passthough send port as a file and the transformation was correct.
My Itinerary
Here are the settings for the routing service
Routing Service Settings
The content-type is application/json.
I tested it using SOAPUI and it returned the content of the data going in.
Here is the Pipeline on the dynamic send port (request/response)
SendPipelineRequest
I believe I read that an ItinerarySelector is not used in the pipeline, because all the information is handled by the ItineraryCache.
I not sure where the issue is. I assume that the content from the transformation will be in the message passed on by the itinerary. Is there a way I can check this with itinerary before calling the service?
I appreciate the help.
UPDATE: No Content. I was doing a transformation through an itinerary service, instead of the pipeline. once I removed the transformation from the itinerary, and added the map to the incoming receive port, the Rest service receive the content, transformed.
We're consuming a web service (web reference, not service reference), and I need a way to output the entire message being sent (including headers) and the message that gets received.
When I add the web reference, the generated base type of the client object to send the messages is System.Web.Services.Protocols.SoapHttpClientProtocol
I send the messages like so:
ApiService api = new ApiService();
// set the certificate and basic http network credentials
var response = api.SendRequest(messageObject);
I'm able to get the body of the request by serializing messageObject, but can't figure out how to get the full message with the headers.
Since I'm using a certificate and basic authentication, tools like Fiddler, etc. aren't getting me what I need, so I believe I have do something programmatically to pull whats sent and whats received prior to being encrypted with ssl.
EDIT
What I want to see if the data being sent and received to another service from within my WCF service.... e.g.:
// this function is within my WCF service
public ResponseModel Auth()
{
// call to another service here... need to trace this
}
If this is for tracing purposes I have had some success using the tracing capabilities of the System.Net libraries, you should be able to enable the tracing through configuration only.
It's described here: How to: Configure Network Tracing
The resulting log file isn't the easiest to follow, but is described here: Interpreting Network Tracing
I created REST base webAPI in MVC 4 and hosted on server when I call this from HTML on other domain and on my local pc I need to call it as JSONP request like put callback=? in url so it can be jsonp. My question is that why this is so? if its due to cross domain then how google and facbook and other companies host their api we also call it from our own domain but we dont keep callback=? in their url.
so why my API need callback=? in url if i call it from other domain or on my local pc with simple jquery html.
Its because of the Same Origin Policy imposed by the browsers.
See
http://www.w3.org/Security/wiki/Same_Origin_Policy
http://en.wikipedia.org/wiki/Same_origin_policy
.
Also note that CORS might be a better option than JSONP in the future
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
EDIT: ------------
If you have gone through above links you would see that JSONP allows users to work-around this Same Origin Policy security measure imposed by the browsers.
Trick is browsers allow tags to refer files in other domains than the origin.
Basically what happens is with JSONP, you send a callback function name to the server appended to the query string. Then the server will pad or prefix it's otherwise JSON request with a call to this function, hence the P in the name to denote response is padded or prefixed.
For example you can create a script tag like
then the target server, should send a response such that
mymethod({normal: 'json response'})
when this repsone is evaluated on the client side (as for any other javascript file) it will effectively call your method with the JSON response from that server.
However, this can only do GET requests.
If you want to make POST (PUT/DELETE) requests you need to use CORS in which server needs to set a specific header beforehand.
Access-Control-Allow-Origin: www.ext.site.com
Hope this helps.
Because of the same-origin policy limitations. The same-origin policy prevents a script loaded from one domain from getting or manipulating properties of a document from another domain. That is, the domain of the requested URL must be the same as the domain of the current Web page. This basically means that the browser isolates content from different origins to guard them against manipulation.
I'm trying to get the raw data sent to IIS using a HttpHandler. However, because the request is an "GET"-request without the "Content-Length" header set it reports that there is no data to read (TotalBytes), and the inputstream is empty. Is there any way I can plug into the IIS-pipeline (maybe even before the request is parsed) and just kind of take control over the request and read it's raw data? I don't care if I need to parse headers and stuff like that myself, I just want to get my hands on the actual request and tell IIS to ignore this one. Is that at all possible? Cause right now it looks like I need to do the alternative, which is developing a custom standalone server, and I really don't want to do that.
Most web servers will ignore (and rarely give you access to) the body of a GET request, because the HTTP semantics imply that it is to be ignored anyway. You should consider another method (for example POST or PUT).
See this question and the link in this answer:
HTTP GET with request body
This is on .Net 4, full framework.
I'm trying to make a simple winforms app that will make some simple WCF REST calls. It's using ChannelFactory and the service contract interface. Of the ~20 methods in the interface, 2 of them involve Stream (an upload and a download method) so the service side (and currently also the client side) using TransferMode=Streamed.
My goal is to include the full HTTP request and response (much like you would see in ethereal/wireshark, or fiddler, or whatever), with headers, in a textbox of the winforms app (just to show what went over the wire)
In trying to use the built-in diagnostics (via SvcConfigEditor) and my own (via implementing IClientMessageInspector and then IEndpointBehavior to add the inspector, then channelFactory.Endpoint.Behaviors.Add to add the behavior :), I'm having 2 issues:
When doing request.ToString() or reply.ToString() in BeforeSendRequest and AfterReceiveReply, it only gets the 'body' and not the headers. Digging around in the objects in the debugger it looks like the reply has them in reply.Properties["httpResponse"], but the request's request.Properties["httpRequest"] has an empty Headers property even though Fiddler shows headers for Content-Type, Host, Accept-Encoding, and Connection. It seems like there's likely a better way to get the 'raw' message that I'm missing (and if there's not, someone probably knows an existing chunk of code to 'reconstruct' the raw one from the Message)
Since the transfer mode is Streamed, the 'body' part just shows up as the string '... stream ...', both in SvcTraceViewer (and the 'raw' svclog - even with logEntireMessage=true) and when doing a ToString(). If the mode is Buffered instead, it shows the actual body fine. I tried making a copy with reply.CreateBufferedCopy(int.MaxValue); but that then caused the actual WCF call to fail with an InvalidOperationException: This message cannot support the operation because it has been copied.
One fallback would be to move the client to Buffered and just change to StreamedRequest for the one upload call and StreamedResponse for the download call (but I'd have to do that programmatically AFAICT, as it's set at the binding level in the config and I don't see anyway of doing it via attributes on the calls), which would take care of the 'body' part and leave me with just the "get the http request headers" (issue #1, specifically request.Properties["httpRequest"].Headers being empty) to deal with, but I'm hoping there's some way of logging the 'raw' messages without doing so, leaving the TransferMode as Streamed.
Thanks!
I can't find any reference right now, but it's a known fact that you cannot capture the contents of a streamed message to WCF tracing. When streaming is enabled, only the headers of the message will be traced.
Here's the source: Configuring Message Logging on MSDN
See towards the end of the page:
Service Level
Messages logged at this layer are
about to enter (on receiving) or leave
(on sending) user code. If filters
have been defined, only messages that
match the filters are logged.
Otherwise, all messages at the service
level are logged. Infrastructure
messages (transactions, peer channel,
and security) are also logged at this
level, except for Reliable Messaging
messages. On streamed messages, only
the headers are logged. In addition,
secure messages are logged decrypted
at this level.