I have a c# "client" and a Java "server". The java server has a wsdl it serves to the client.
So far it works for c# to make a request for the server to perform a soap action. My server gets the soap request executes the method and tries to return the result back to the client.
When I send the response to c# however, I get "The server committed a protocol violation. Section=ResponseStatusLine".
I have spent all day trying to fix this and have come up with nothing that works. If I explain what i did, this post would be very long, so I'll keep it brief.
i Googled for hours and everything tells me my "response line" is correct. I tried shutting down Skype, rearranging the response line, adding things, taking things away, etc, etc. All to no avail.
This is for a class assignment so no, I can not use apis to help. I must do everything manually on the server side. That means parsing by hand, creating the soap response and the http response by hand. Just thought you'd like to know that before you say to use something that does it for me.
I even tried making sure my server was sending the correct header by creating a java client that "mimicked" the c# one so I could see what the server returned. However, it's returning exactly what i told it to send.
I tried telling my java client to do the same thing but to an actuall running c# service, to see what a real service returns, and it returned basically the same thing. To be safe, I copied it's response and tried sending it to the c# client and it still threw the error.
Can anyone help? I've tried all i can think of, including adding the useUnsafeHeaderParsing to my app config. Nothing is working though. I send it exactly what a real service sends it and it yells at me. I send it what i want and it yells.
I'm sending this:
"200 OK HTTP/1.0\r\n" +
"Content-Length: 201\r\n" +
"Cache-Control: private\r\n" +
"Content-Type: text/xml; charset=utf-8\r\n\r\n";
The reason for your error is that you've got the status line syntax wrong. According to the RFC, the status line syntax is:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
You got the parts of the response status line around the wrong way ... like the error message is telling you!
Some advice:
Don't try to talk HTTP or SOAP at this level. These protocols are complicated, and there are existing well-implemented, well-document libraries that do this kind of thing. Use them and don't waste your time reinventing the wheel.
If you really do want / need to implement this stuff yourself, it is CRITICAL that you read and understand the relevant specifications. They are easy to find using Google.
(I'm not going to provide links because that would only encourage you to waste your time on building the software equivalent of horse carts with square wheels. because you need to learn to find and use them yourself ... as a matter of course.)
Related
I'm working on changes for an old user creation endpoint in a dotnet API.
In a specific endpoind for the creation of users, besides many things i'm calling Zerobounce API to validate the email of the user.
In the application that get's the response from this API it needs to act differently if the issue comes from Zerobounce, which is an email validation API.
What i've already done is:
When it fails i'll return a response with a status code 409. Which i'm not sure is the best choice but seemed fine at the beginning, but is now a problem since it can be returned in another case that doesn't involve Zerobounce .
The complete response when an error is returned is of the type:
Different solutions i thinked about:
Different ReasonPhrase for each different error with the same status code. Which means for Zerobounce errors i can tell there whats happening.
Using custom Response Headers, with this i can create for example 2 headers, one that creates a sub status code and another with the reason of failure or something else. this seems more versatile.
Start sending a body in case it fails, this might involve lots more changes, because the way the api, and website that calls the endpoint only expects a body when we have a success response, god knows where else it might break if i use this approach.
Any suggestion as the best approach is appreciatted.
I'm trying to implement Negotiate (at least the Kerberos part) in a small web server. I've figured out how to get a client to send me a Kerberos Negotiate Authorization header. I've figured out how to decode that data (ASN.1). I cannot figure out how to turn this into a WindowsIdentity. I can get a general idea of how I might from KerberosReceiverSecurityToken, but I can't find anything like a NegotiateReceiverSecurityToken. I've been digging through lots of DLLs and I can't for the life of me figure out where IIS/.NET processes the Negotiate header.
I presume (if I had my own SspiWrapper) that I would do something with SspiWrapper.AcquireDefaultCredential("Negotiate", CredentialUse.Inbound) to acquire an SSPI context with which I could call AcceptSecurityContext/Negotiate and then use QuerySecurityContextToken to get the token with which I could create a WindowsIdentity.
But KerberosReceiverSecurityToken makes that look like an immensely complicated process. And without any idea of how to do that or what part of the Authorization header payload to put into it, I could probably beat my head against it for a month without getting anywhere.
(Before you ask or answer, I have absolutely no interest in using the built in Negotiate logic. If I could find it, I would learn from it, but I've been trying to get that to work for FAR to long. And I'm done with that.)
Parse the incoming response token
Call Secur32.AcquireCredentialsHandle to get a handle
Call Secur32.AcceptSecurityContext passing the handle and the token
Call Secur32.QuerySecurityContextToken passing the security context
Construct a new WindowsIdentity(hToken) using the output form step 4
If you have any questions about any of these steps, I can elaborate and/or provide some sample code.
a few days ago I start to use a SOAP service for Joomla and VirtueMart connected by a client in C#.
I tried out about a fistful functions and it works fine.
Only one function I've trouble with when I try to use it I get an error.
The developer send me a request that work for him (with my server) but I see only few differents that are not important as I think ...
Maybe somebody can help and show me impoartant differents of the requests that may be a reason for trouble?
This is the working request done with Felx (as URL as I can't insert XML:
Working Request
And this is my request that return a server fault:
Not working Request
Has somebody any idea please?
Fiddler also return an violation but I think that does not matter in this case:
Content-Length mismatch: Response Header indicated 8.958 bytes, but server send 8.959 bytes.
Also a hint how to debug may be useful.
I've got an app in the Windows 8 store that uses a WCF service hosted on Azure. When I use my proxy program, UltraSurf, the app fails to connect to the service with this error:
The content type text/html 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. The first 472 bytes of the response were:
'
The requested URL could not be retrieved
'.
The URL mentioned in the quote is the default 'can't find the page Url' that UltraSurf produces and so the error message is probably of no use. The question is, why/how does Ultrasurf block/get in the way of my connection?
Can anybody shed some light on what's going on and why it fails connect please?
Thanks!
Working without much information here, but I'd suspect that the problem is that the proxy is just being a little picky.
I believe that your error message basically says, "I'm expecting to get back 'text/xml' data, but what I see is 'text/html' data". That's probably not because it can actually see 'text/html' data coming back, but rather, because it's not seeing the content type header from the response telling it that it is xml data.
I don't know exactly how you implemented your WCF service, or what type of data it's set up to return, but you might want to ensure that you explicitly set the content type somewhere in your code before the return and see what happens. Something like:
Response.ContentType = "text/xml";
The only other thing that springs to mind is that your application might be picky about the content type for XML in general. There's a bit of, um... subtle difference... around whether the appropriate content type for XML is 'application/xml' or 'text/xml'. It's possible that your service is presenting the one that your proxy doesn't like?
Ok this has been driving me nuts now for about 12 hours. I have a C# web service running under IIS 7 and I am connecting to it via PHP on a Apache 2.2 box. Not that any of that should really matter but figured I would drop it in.
Now when I go directly to the web service and invoke it I get the correct datetime format but if I call it from php I do not.
Example:
C# WebService: 6/4/2009 9:23:25 AM
PHP Soap Result: 12/31/1600 4:00:00 PM
The WebService is assessing WMI::Win32_LogonSession to get the StartTime and then being converted via ManagementDateTimeConverter.ToDateTime((string)wmisearcherData["StartTime"])
and then set to a string.
Im at a lose anything anyone has to offer would be a great help.
Thanks
I don't think it's getting an incorrect time. PHP is getting "no time at all", and the time value you see is a default value. The beginning of the epoch, as they say. Regardless what value you send, it will always be the same time. This will happen if the format of the XML sent on the wire does not comply with the PHP client's expectations. Actually this is true with any pair of interoperating platforms, not just C# and PHP.
When you use a web service proxy library, the code implicitly maps in and out variables to incoming and outgoing XML documents (or more accurately, XML fragments). Sometimes apps do XML Serialization explicitly, but web services stacks do it implicitly.
There are a variety of reasons why XML de-serialization would fail on the client side. In my experience, the most common cause is a simple XML namespace mismatch. The difference of a single slash on a namespace between the client and server means the XML is not the same. Once I helped a client who fought for days with an XML de-serialization problem like this. Turns out one namespace on his server was missing a slash - someone had innocently trimmed it off for aesthetic reasons.
Aside from XML element name and namespace discrepancies, Date and time formats are a known source of interop problems in web services. That's because there are so many ways to format a time. Is 2006-Jun-14 the same as 2006/06/14? Does 4/7/2007 mean the 4th of July or the 7th of April? Beyond just the formatting issues, you have to concern yourself with the relative meaning of the time value. Is it UTC? Localtime? If it is local, how do you indicate the timezone value?
If anyone else has this problem, here's something you can do to help sort it:
set a debugging http proxy up between the service and the client. Like Fiddler2, or Charles, or Burp or proxyTrace. That way you can inspect the XML on the wire, which will help you figure out why the PHP app is not getting the result you desire.
Often when I have these interop glitches, I will set up a mock service using a homogeneous client and server. In your case this would be a PHP client talking to a PHP server. Using the debugging proxy, look at the traffic generated by the PHP server, which is accepted correctly by the PHP client. You will have to duplicate that in any other service. You can then use the proxy to verify that the content delivered by your actual services complies with what PHP is expecting.
Try this:
ManagementDateTimeConverter.ToDateTime((string)wmisearcherData["StartTime"]).ToString("yyyy/MM/dd HH:mm:ss")
PHP should interpret that correctly.