开发者

Getting Gibberish instead of Hello World from a service with webHttpBinding

开发者 https://www.devze.com 2023-01-18 06:08 出处:网络
Here is a trivial example that is supposed to return \"Hello World\" string. However, a browser displays something like SGVsbG8gV29ybGQ=. Which is the right way to return plain text from an oldskul-st

Here is a trivial example that is supposed to return "Hello World" string. However, a browser displays something like SGVsbG8gV29ybGQ=. Which is the right way to return plain text from an oldskul-style service?

please know that:

  1. I can't return a string: three Unicode characters will be automatically prepended and the legacy HTTP client won't be able to interoperate.

  2. I could return a Message, but still must keep parsing functionality to extract the data variable. Mixing Message and int types in the same method signature is not allowed AFAIK. 开发者_如何学运维

    [ServiceContract(SessionMode=SessionMode.NotAllowed)] 
    public interface IHello 
    {
      [WebGet(UriTemplate = "manager?data={data}")]
      [OperationContract]
      Byte[] DoIt(int data);
    }

    public class Hello : IHello { public Byte[] DoIt(int data) { return Encoding.ASCII.GetBytes("HelloWorld"); } }

UPDATE: It's not gibberish, but correctly encoded response. However, the format is not what I'd expect to receive. I've figured out (as gentlemen below suggest) that the ultimate control of the transport layer messaging format is gained with Message class. However, if I do use one - I loose the possibility of parsing the request (UriTemplate attribute). Hence, it would be great to know how to integrate the Message with UriRequest.

P.S. If the "clean" integration is not possible - than what's the most elegant workaround? Is there any code that is done behind the wire curtain that I can borrow and use in my implementation, please?


That's not gibberish - it's the base64-encoded version of the ASCII bytes for "Hello World" (with a space).

When you ask a web service to transmit bytes, it will use base64... your web service client will perform the base64 decoding automatically, to get you back the original bytes.

(I wouldn't suggest using Encoding.ASCII, mind you.)

It's not clear what your "legacy HTTP client" is, or what it's expecting, so we can't really tell whether returning a byte array is actually the best answer or not.


Googled for a proper way to integrate and found that people are stuck just as I am (please correct me if I am wrong on that). So far the following workaround works fine for me:

  public class Hello : IHello
  {
        [WebGet(UriTemplate = "manager")]
        [OperationContract]
        Message DoIt();
  }

  public class Hello : IHello
  {
        public Message DoIt()
        {
          var webContext = WebOperationContext.Current;
          var request = webContext.IncomingRequest;
          var queryParameters = request.UriTemplateMatch.QueryParameters;
          var data = queryParameters["data"];

          var result = new StringBuilder(@"
              <?xml version='1.0'?>
              ...
          ");

          var response = webContext.CreateTextResponse(result.ToString(), "application/xml", Encoding.ASCII);

          return response;
        }
  }

If there is a better alternative - it would be perfect to know about it.


The SOAP specification states that raw binary data should be base64 encoded. So the behavior you witness is correct.

If you need to transmit ASCII character data. You can use one message contract and a raw Message.

Message DoIt(DoItRequest request)

The raw message will create the response containing ASCII data. The message contract is used to retrieve the int parameter you mentioned:

[MessageContract]
public class DoItRequest
{
  [MessageBodyMember] public int data;
}

This page explains how to work with the Message class.

0

精彩评论

暂无评论...
验证码 换一张
取 消