I have an issue when I try to retrieve info through a webmethod. I am using a proxy to call a web service, in that proxy I have an operation which returns data using 'out' parameters.
The server executes the operation succesfully, giving back the parameters properly instanced (I also have checked the soap return message using a traffic analyzer and is ok), but when I ask for those parameters to the proxy, I only obtain null values.
Here is some code info:
//This is the call to the web service using the proxy (t is the proxy and get_capabilities is the webmethod)
public trf_capabilities get_capabilities() {
trf_capabilities trfcap = new trf_capabilities();
trfcap.protocol_list= t.get_capabilities(0, out trfcap.pause, out trfcap.maxfiles, out trfcap.maxsize, out trfcap.encrypt, out trfcap.authenticate, out trfcap.integritycheck, out trfcap.hashtype, out trfcap.multipath, out trfcap.profile_list);
return trfcap;
}
//This is the webMethod definition
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("iTransfer-get_capabilities",/*RequestElementName="elementoVacio_",*/ RequestNamespace="", ResponseElementName="trf_capabilitiesPar", ResponseNamespace="", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
[return: System.Xml.Serialization.XmlElementAttribute("protocol_list", Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public protocolType[] get_capabilities([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] int vacio, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out bool pause, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out uint maxfiles, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out uint maxsize, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out bool encrypt, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out bool authenticate, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out bool integritycheck, [System.Xml.Serialization.XmlElementAttribute("hash_type", Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out hash_typeType[] hash_type, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out bool multipath, [System.Xml.Serialization.XmlElementAttribute("profile_list", Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] out profile_listType[] profile_list) {
object[] results = this.Invoke("get_capabilities", new object[] {
vacio});
pause = ((bool)(results[1]));
maxfiles = ((uint)(results[2]));
maxsize = ((uint)(results[3]));
encrypt = ((bool)(results[4]));
authenticate = ((bool)(results[5]));
integritycheck = ((bool)(results[6]));
hash_type = ((hash_typeType[])(results[7]));
multipath = ((bool)(results[8]));
profile_list = ((profile_listType[])(results[9]));
return ((protocolType[])(results[0]));
}
As you can see, I am using the 'out' token in both call and handler method, but it seems is not enough to get the correct behaviour.
And finally, here is the SOAP message intercepted with the traffic analyzer:
Content-Type: text/xml; charset=UTF-8
Server: SOAPStandaloneServer
Content-Length: 584
Connection: close
<E:Envelope xmlns:E="http://schemas.xmlsoap.org/soap/envelope/" xmlns:A="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.w3.org/2001/XMLSchema"><E:Body><ns1:get_capabilitiesResponse xmlns:ns1=""><ns1:pause>true</ns1:pause><ns1:maxfiles>5</ns1:maxfiles><ns1:maxsize>0</ns1:maxsize><ns1:encrypt>true</ns1:encrypt><ns1:authenticate>true</ns1:authenticate><ns1:integritycheck>true</ns1:integritycheck><ns1:multipath>true</ns1:multipath></ns1:get_capabilitiesResponse></E:Body></E:Envelope>
Any ideas?
I think you're on the right track with [decoration] and serializing the answers. the arrays in there seem a bit tricky, do you have serialization routines for the elements in them?
Then again, having that amount of output parameters seems kind of overwhelming. I would probably have created a "ServiceResponse" struct and added all the params as properties in it.
EDIT: Next step, if the response seems ok but the proxy has problems deserializing it, I would suggest (of course) delving deeper into the proxy. Is the proxy generated or have you written it manually? Try to step through it and see what it tries to do with the parameters it's been given. Often I hack about with web services till my eyes bleed, only to discover that the deserialization spec was obsolete.
I found something interesting about all of this. I have been checking the headers of the two types of web methods I have (the one written in C++ I have to use and the test one I developed in C#). I realised that, for out parameters, .NET add some kind of wrapping.
Here comes the msdn explanation:
The XML portion of the SOAP response encapsulates the out parameters for the Web service method, including the result inside an element. The name of the encapsulating element, by default, is the name of the Web service method with Response appended to it.
Here is the link
It seems you have to use that wrapper in order to get 'out' reference parameters working.
Related
I have a GRPC API where, following a refactor, a few packages were renamed. This includes the package declaration in one of our proto files that defines the API. Something like this:
package foo;
service BazApi {
rpc FooEventStream(stream Ack) returns (stream FooEvent);
}
which was changed to
package bar;
service BazApi {
rpc FooEventStream(stream Ack) returns (stream FooEvent);
}
The server side is implemented using grpc-java with scala and monix on top.
This all works fine for clients that use the new proto files, but for old clients that were built on top of the old proto files, this causes problems: UNIMPLEMENTED: Method not found: foo.BazApi/FooEventStream.
The actual data format of the messages passed over the GRPC API has not changed, only the package.
Since we need to keep backwards compatibility, I've been looking into a way to make the old clients work while keeping the name change.
I was hoping to make this work with a generic ServerInterceptor which would be able to inspect an incoming call, see that it's from an old client (we have the client version in the headers) and redirect/forward it to the renamed service. (Since it's just the package name that changed, this is easy to figure out e.g. foo.BazApi/FooEventStream -> bar.BazApi/FooEventStream)
However, there doesn't seem to be an elegant way to do this. I think it's possible by starting a new ClientCall to the correct endpoint, and then handling the ServerCall within the interceptor by delegating to the ClientCall, but that will require a bunch of plumbing code to properly handle unary/clientStreaming/serverStreaming/bidiStreaming calls.
Is there a better way to do this?
If you can easily change the server, you can have it support both names simultaneously. You can consider a solution where you register your service twice, with two different descriptors.
Every service has a bindService() method that returns a ServerServiceDefinition. You can pass the definition to the server via the normal serverBuilder.addService().
So you could get the normal ServerServiceDefinition and then rewrite it to the new name and then register the new name.
BazApiImpl service = new BazApiImpl();
serverBuilder.addService(service); // register "bar"
ServerServiceDefinition barDef = service.bindService();
ServerServiceDefinition fooDefBuilder = ServerServiceDefinition.builder("foo.BazApi");
for (ServerMethodDefinition<?,?> barMethodDef : barDef.getMethods()) {
MethodDescriptor desc = barMethodDef.getMethodDescriptor();
String newName = desc.getFullMethodName().replace("foo.BazApi/", "bar.BazApi/");
desc = desc.toBuilder().setFullMethodName(newName).build();
foDefBuilder.addMethod(desc, barMethodDef.getServerCallHandler());
}
serverBuilder.addService(fooDefBuilder.build()); // register "foo"
Using the lower-level "channel" API you can make a proxy without too much work. You mainly just proxy events from a ServerCall.Listener to a ClientCall and the ClientCall.Listener to a ServerCall. You get to learn about the lower-level MethodDescriptor and the rarely-used HandlerRegistry. There's also some complexity to handle flow control (isReady() and request()).
I made an example a while back, but never spent the time to merge it to grpc-java itself. It is currently available on my random branch. You should be able to get it working just by changing localhost:8980 and by re-writing the MethodDescriptor passed to channel.newCall(...). Something akin to:
MethodDescriptor desc = serverCall.getMethodDescriptor();
if (desc.getFullMethodName().startsWith("foo.BazApi/")) {
String newName = desc.getFullMethodName().replace("foo.BazApi/", "bar.BazApi/");
desc = desc.toBuilder().setFullMethodName(newName).build();
}
ClientCall<ReqT, RespT> clientCall
= channel.newCall(desc, CallOptions.DEFAULT);
TL; DR I have an ASP.NET 5 (MVC 6) application and just trying to set a HTTP Content-Length header in order to avoid chunked response.
To my surprise, it happens that this is a quite tricky task to accomplish in ASP.NET 5. Everything is running on Kestrel which from ASP.NET 5 Beta7 supports writing chunked responses automatically when no content length is specified for the response.
There is a similar question here, but the difference is that the OP just wants to count a response size, while I need to ensure that the Content-Length header is sent within a response. Tried with many things so far, and the only thing that works is writing a custom Middleware:
public class WebApiMiddleware {
RequestDelegate _next;
public WebApiMiddleware(RequestDelegate next) {
_next = next;
}
public async Task Invoke(HttpContext context) {
using (var buffer = new MemoryStream()) {
var response = context.Response;
var bodyStream = response.Body;
response.Body = buffer;
await _next(context);
response.Headers.Add("Content-Length", new[] { buffer.Length.ToString()});
buffer.Position = 0;
await buffer.CopyToAsync(bodyStream);
}
}
}
However, this is highly inefficient since we are using additional memory while processing every request. Using a custom stream that just wraps around the context.Response.Body stream and additionally counts bytes doesn't work since the Microsoft team states that once the amount of data they're willing to buffer has been written, it goes out on the wire and they don't store it any more, so I can, at best, add Content-Length to the last chunk which is not the wished behavior - I want to avoid chunking completely.
Any help is highly appreciated!
p.s. I am aware that chunking is a regular feature of HTTP/1.1, but in my scenario it degrades performance so I want to avoid it without forcing the clients to send HTTP/1.0 requests.
You need to send header before sending response so you need to store whole response before sending it to determine length.
As you said context.Response.Body stream doesn't store to much before sending so overhead is not that big.
There is middleware that does similar thing: https://github.com/aspnet/BasicMiddleware/blob/master/src/Microsoft.AspNetCore.Buffering/ResponseBufferingMiddleware.cs it is very similar to what you wrote but supports additional features like IHttpBufferingFeature to allows other middleware control buffering.
Checking for bufferStream.CanSeek is there to make sure nobody already wrapped response stream into buffering stream and avoid double buffering.
For your second question: this place is middlware.
How does one read the request body in ASP.NET? I'm using the REST Client add-on for Firefox to form a GET request for a resource on a site I'm hosting locally, and in the Request Body I'm just putting the string "test" to try to read it on the server.
In the server code (which is a very simple MVC action) I have this:
var reader = new StreamReader(Request.InputStream);
var inputString = reader.ReadToEnd();
But when I debug into it, inputString is always empty. I'm not sure how else (such as in FireBug) to confirm that the request body is indeed being sent properly, I guess I'm just assuming that the add-on is doing that correctly. Maybe I'm reading the value incorrectly?
Maybe I'm misremembering my schooling, but I think GET requests don't actually have a body. This page states.
The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body.
So maybe you're doing things correctly, but you have to POST data in order to have a message body?
Update
In response to your comment, the most "correct" RESTful way would be to send each of the values as its own parameter:
site.com/MyController/MyAction?id=1&id=2&id=3...
Then your action will auto-bind these if you give it an array parameter by the same name:
public ActionResult MyAction(int[] id) {...}
Or if you're a masochist you can maybe try pulling the values out of Request.QueryString one at a time.
I was recently reminded of this old question, and wanted to add another answer for completeness based on more recent implementations in my own work.
For reference, I've blogged on the subject recently.
Essentially, the heart of this question was, "How can I pass larger and more complex search criteria to a resource to GET a filtered list of objects?" And it ended up boiling down to two choices:
A bunch of GET query string parameters
A POST with a DTO in the request body
The first option isn't ideal, because implementation is ugly and the URL will likely exceed a maximum length at some point. The second option, while functional, just didn't sit right with me in a "RESTful" sense. After all, I'm GETting data, right?
However, keep in mind that I'm not just GETting data. I'm creating a list of objects. Each object already exists, but the list itself doesn't. It's a brand new thing, created by issuing search/filter criteria to the complete repository of objects on the server. (After all, remember that a collection of objects is still, itself, an object.)
It's a purely semantic difference, but a decidedly important one. Because, at its simplest, it means I can comfortably use POST to issue these search criteria to the server. The response is data which I receive, so I'm "getting" data. But I'm not "GETting" data in the sense that I'm actually performing an act of creation, creating a new instance of a list of objects which happens to be composed of pre-existing elements.
I'll fully admit that the limitation was never technical, it was just semantic. It just never "sat right" with me. A non-technical problem demands a non-technical solution, in this case a semantic one. Looking at the problem from a slightly different semantic viewpoint resulted in a much cleaner solution, which happened to be the solution I ended up using in the first place.
Aside from the GET/POST issue, I did discover that you need to set the Request.InputStream position back to the start. Thanks to this answer I found.
Specifically the comment
Request.InputStream // make sure to reset the Position after reading or later reads may fail
Which I translated into
Request.InputStream.Seek(0,0)
I would try using the HttpClient (available via Nuget) for doing this type of thing. Its so much easier than the System.Net objects
Direct reading from the Request.InputStream dangerous because when re-reading will get null even if the data exists. This is verified in practice.
Reliable reading is performed as follows:
/*Returns a string representing the content of the body
of the HTTP-request.*/
public static string GetFromBodyString(this HttpRequestBase request)
{
string result = string.Empty;
if (request == null || request.InputStream == null)
return result;
request.InputStream.Position = 0;
/*create a new thread in the memory to save the original
source form as may be required to read many of the
body of the current HTTP- request*/
using (MemoryStream memoryStream = new MemoryStream())
{
request.InputStream.CopyToMemoryStream(memoryStream);
using (StreamReader streamReader = new StreamReader(memoryStream))
{
result = streamReader.ReadToEnd();
}
}
return result;
}
/*Copies bytes from the given stream MemoryStream and writes
them to another stream.*/
public static void CopyToMemoryStream(this Stream source, MemoryStream destination)
{
if (source.CanSeek)
{
int pos = (int)destination.Position;
int length = (int)(source.Length - source.Position) + pos;
destination.SetLength(length);
while (pos < length)
pos += source.Read(destination.GetBuffer(), pos, length - pos);
}
else
source.CopyTo((Stream)destination);
}
Is there a simple explanation on MSDN of WebForm_DoCallback function?
All I can find is this article http://msdn.microsoft.com/en-us/magazine/cc163878.aspx
which does include implementation of WebForm_DoCallback but doesn't do a good job explaining parameters themselves.
function WebForm_DoCallback(eventTarget, eventArgument,
eventCallback, context, errorCallback)
Like what exactly does it expect as an 'eventTarget'?
What is 'context'?
Etc...
WebForm_DoCallback appears to be the client-side counterpart to GetCallbackEventReference. It's generated with the same arguments, which are as follows:
target: The name of a server Control that handles the client
callback. The control must implement
the ICallbackEventHandler interface
and provide a RaiseCallbackEvent
method.
argument: An argument passed from the client script to the server
RaiseCallbackEvent method.
clientCallback: The name of the client event handler that receives the
result of the successful server event.
context: Client script that is evaluated on the client prior to
initiating the callback. The result of
the script is passed back to the
client event handler.
clientErrorCallback: The name of the client event handler that receives
the result when an error occurs in the
server event handler.
useAsync: true to perform the callback asynchronously; false to
perform the callback synchronously.
clientCallback and clientErrorCallback are client-side (usually javascript) functions with arguments in the form:
function clientCallback(returnmessage, context) {}
Where returnmessage is the response from the server (or error) and context is the same as the context passed in previously.
References:
MSDN: ClientScriptManager.GetCallbackEventReference Method
MSDN Magazine: Implications of Script Callbacks in ASP.NET
ESRI Developer Network: Page Postbacks and Client Callbacks
we can see something like this--
WebForm_DoCallback('__Page',parameter,callBack,context,null,false);
in the page resource file.
it seems the 'parameter' is a value type(string), while the context is a ref type.
anyway the "context" is rarely used.
the "Parameter" could only be a string, so you may need combine several values into it, and then separate it on the server.
while the data is transmitted to the server end, the relative class(as a subclass of interface 'ICallbackEventHandler') instant will be created, and the handler method will be called:
public void RaiseCallbackEvent(string eventArgument)
{
//deal with the eventArgument( the "parameter")
}
after that another method goes on and return a string back in the response..
public string GetCallbackResult()
{
//return command;
}
finally the async process raises the callback function( "callBack" in this case),which should has 2 input params:
function callBack(returnedStuff, context) {......}
and that's how it works
however I don't know where the javascript function "WebForm_DoCallback" is defined, so it may not work on the non-windows computers.
To what context do you need to use this with? The string is generated by the following method call in ClientScriptManager: http://msdn.microsoft.com/en-us/library/ms153110%28v=VS.100%29.aspx
Using this is what you can use to produce the above statement, without having to know the details.
HTH.
I need to send a HTTP request (and get XML response) from Flash that looks similar to following:
http://example.com/somepath?data=1&data=2&data=3
I.e. having several parameters that share same name, but have different values.
Until now I used following code to make HTTP requests:
var resp:XML = new XML();
resp.onLoad = function(success:Boolean) {/*...*/};
resp.ignoreWhite = true;
var req:LoadVars = new LoadVars();
req["someParam1"] = 3;
req["someParam2"] = 12;
req.sendAndLoad("http://example.com/somepath", resp, "GET");
In this case this will not do: there will be only one parameter having last value.
What are my options? I'm using actionscript 2.
Added
I guess, I can do something like that:
var url:String = myCustomFunctionForBuildingRequestString();
var resp:XML = new XML();
resp.onLoad = function(success:Boolean) {/*...*/};
resp.load(url);
But in that case I am loosing ability to do POST requests. Any alternatives?
Changing request is not appropriate.
The standard http way of sending array data is
http://example.com/?data[0]=1&data[1]=2
But this isn't wrong either (added from comment):
http://example.com/?data[]=1&data[]=2
Sending more parameters with the same name like you're doing, in practice means that all but the last item should be ignored. This is because when reading variables, the server overwrites (in memory) any item that has the same name as that one, because renaming a variable isn't good practice and never was.
I don't know much AS (none :p) but you'd access it as a list or array or whatever data structures it has.
Although POST may be having multiple values for the same key, I'd be cautious using it, since some servers can't even properly handle that, which is probably why this isn't supported ... if you convert "duplicate" parameters to a list, the whole thing might start to choke, if a parameter comes in only once, and suddendly you wind up having a string or something ... but i guess you know what you're doing ...
I am sorry to say so, but what you want to do, is not possible in pure AS2 ... the only 2 classes available for HTTP are LoadVars and XML ... technically there's also loadVariables, but it will simply copy properties from the passed object into the request, which doesn't change your problem, since properties are unique ...
if you want to stick to AS2, you need an intermediary tier:
a server to forward your calls. if you have access to the server, then you create a new endpoint for AS2 clients, which will decode the requests and pass them to the normal endpoint.
use javascript. with flash.external::ExternalInterface you can call JavaScript code. You need to define a callback for when the operation is done, as well as a JavaScript function that you can call (there are other ways but this should suffice). Build the request string inside flash, pump it to JavaScript and let JavaScript send it to the server in a POST request and get the response back to flash through the callback.
up to you to decide which one is more work ...
side note: in AS3, you'd use flash.net::URLLoader with dataFormat set to flash.net::URLLoaderDataFormat.TEXT, and then again encode parameters to a string, and send them.
Disclaimer; I've never used Actionscript and have no means for testing this.
Putting the same variable name with several values on the query string is the standard way of sending multi-value variables (for example form checkboxes) to web servers. If LoadVars is capable of sending multiple values then it seems plausible that the values should be stored in an array:
req["someParam1"] = ["foo","bar","bas"];
There also seems to be a decode function to LoadVars, what happens if you try to import the query string you want into the object?:
req.decode("someParam1=foo&someParam1=bar&someParam1=bas");
You cannot use loadvars like this - because data can be either 1 or 2 or 3, not all of them at the same time.
You can either pass it as a comma separated list:
var req:LoadVars = new LoadVars();
req["data"] = "1,2,3";
or as an xml string, and parse it at the server. I am not familiar with manipulating xml in AS2, but this is how you'd do it in AS3:
var xml:XML = <root/>;
xml.appendChild(<data>1</data>);
xml.appendChild(<data>2</data>);
xml.appendChild(<data>3</data>);
//now pass it to loadvars
req["data"] = xml.toXMLString();
The string you send is:
<root>
<data>1</data>
<data>2</data>
<data>3</data>
</root>