• 0

[C#] Am I missing a pitfall with base64 encode sending?


Question

I am always learning different parts of the C# language b/c lets face it, it's a lot of fun :). I've decided to configure my wcf service as a rest service which supports json request/response instead of xml. All has gone well and I can serialize/deserialize my messages into complex classes so far, unless I send a bunch of data in them. I've tried to change my readerQuotas, etc, etc but everytime I try to make a call it says "Error: Bad Data". I know the service works because I can call simple functions and pass data to/from the service. But if I pass a class with 3 byte[] properties each 128 bytes in length it fails. If I pass the same class with each byte[] param with 3 bytes of data it goes through (I base64 encode each complex class after serializing them). Here is my example code:

This example passes and goes through:

GetTestSalesRequest req = new GetTestSalesRequest()
			{
				CurrentTest = new byte[] { 1 },
				CurrentMTest = new byte[] { 4 },
				UserName = this.gl_userName,// <---- is a string
				UserPwd = new byte[] { 2 }
			};

string test = await this.gl_client2.TestFunc(req);
			System.Diagnostics.Debug.WriteLine("Testtion: {0}", test);

This example fails.

GetTestSalesRequest req = new GetTestSalesRequest()
			{
				CurrentTest = CryptographicEngine.Encrypt(keySvr, Encoding.UTF8.GetBytes(test1.ToString()).AsBuffer(), null).ToArray(), // <---- is a byte[]
				CurrentMTest = CryptographicEngine.Encrypt(keySvr, Encoding.UTF8.GetBytes(test2.ToString()).AsBuffer(), null).ToArray(), //<---- is a  byte[]
				UserName = this.gl_userName,// <---- is a string
				UserPwd = this.gl_userPwd // <--- is a byte[]
			};

string test = await this.gl_client2.TestFunc(req);
			System.Diagnostics.Debug.WriteLine("Testtion: {0}", test);

public async Task<string> TestFunc(GetTestSalesRequest request)
		{

string resBody = null;
			byte[] testStr = Encoding.UTF8.GetBytes(WebHelperClass.SerializeJSONObj<GetTestSalesRequest>(request));
			string addr = string.Format("{0}/TestFunc/{1}", this.gl_baseAddr, Convert.ToBase64String(testStr));
			WebRequest req = WebRequest.Create(addr);
			HttpWebResponse res = await req.GetResponseAsync() as HttpWebResponse;
			if (res.StatusCode == HttpStatusCode.OK)
			{
				using (Stream stream = res.GetResponseStream())
				{
					using (StreamReader sr = new StreamReader(stream))
					{
						resBody = sr.ReadToEnd();
						sr.Dispose();
					}
				}
			}
			return resBody;
}

Is there a pitfall I'm going into here? What am I missing that is really obvious because this has to be possible to be done.

10 answers to this question

Recommended Posts

  • 0

Not really strong with debugging other peoples code.. But.. have you tried:

1) Sending the same data but un-encrypted

2) Using AsciiEncoding.Ascii instead of Encoding.UTF8 for the base64 encode?

3) It looks like you are just using the CryptographicEngine, that won't base64 it, have you tried just a plain-jane base64 encode?

4) You pass in a few variables, are you sure they are all initialized correctly?

  • 0

Well basically I'm just taking the json string (that was created by serializing the complex class) in TestFunc and base64 encoding it to send it across to the rest service so I don't have a long query string similar to /TestFunc/{[80,10,01,01,30,10,10], "test":"etc"}. So I am base64 encoding the whole thing then decoding it on the rest service side. If I send the class with only have small amounts of byte data it goes through just fine. If I send each byte[] with having 128 different indexes each then it fails. Ingramator which files do you want? The debugger just outputs saying "The remote server returned an error: (400) Bad Request."

System.Net.WebException was unhandled by user code

HResult=-2146233079

Message=The remote server returned an error: (400) Bad Request.

Source=System

StackTrace:

at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)

at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

at TestSaleStoreApp.TestSaleRestSvcClient.<TestFunc>d__a.MoveNext() in c:\Users\User\Documents\Visual Studio 2012\Projects\TestSaleStoreApp\TestSaleStoreApp\TestSaleRestSvcClient.cs:line 50

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

at TestSaleStoreApp.MainUserPg.<initSettings>d__16.MoveNext() in c:\Users\User\Documents\Visual Studio 2012\Projects\TestSaleStoreApp\TestSaleStoreApp\MainUserPg.xaml.cs:line 524

InnerException:

If you need more info let me know :) I'm stumped on this one. As for the ASCII I haven't tried that yet I'll look into it later today but I'm suspecting it has to do with the length of the content (which I've changed the readerQuota settings).

I also really appreciate the help so far guys!

  • 0

It's quite possible you're just sending too much data via the query string, why aren't you just sending it as the request body instead?

base64 makes the content larger, and you don't need to do it with text (like JSON).

  • 0

@The_Decryptor b/c I'm new to using Rest services I'm used to using SOAP :) I'll look into that thanks.

EDIT: My url looks like this:

localhost:8733/Design_Time_Addresses/TestSaleRestSvc/Service1/TestFunc/eyJDdXJyZW50Q29vcmRzTGF0IjpbMiwzLDRdLCJDdXJyZW50Q29vcmRzTG9uZyI6WzMsNCw1XSwiVXNlck5hbWUiOiJyeWFuIiwiVXNlclB3ZCI6WzFdfQ==&pwdKey=Aw==&latKey=JbU2hfwNBi1vHZxH5OnUcKabsT1kx16jqn3BAxLDXPTCHbyIlDyPOoK0NNQVSLmaOD5x1bjzipTM9VJOaQgTIgjmqNtX+l9Jq2EeetSQI58RhCwUFRQGOpKaLEJ03JeZ5UjD3rTzm2HFr5P0SvQBYBsgLB9W1je3PPoD28Ro7IU=&longKey=AQ=="]localhost:8733/Design_Time_Addresses/TestSaleRestSvc/Service1/TestFunc/eyJDdXJyZW50Q29vcmRzTGF0IjpbMiwzLDRdLCJDdXJyZW50Q29vcmRzTG9uZyI6WzMsNCw1XSwiVXNlck5hbWUiOiJyeWFuIiwiVXNlclB3ZCI6WzFdfQ==&pwdKey=Aw==&latKey=JbU2hfwNBi1vHZxH5OnUcKabsT1kx16jqn3BAxLDXPTCHbyIlDyPOoK0NNQVSLmaOD5x1bjzipTM9VJOaQgTIgjmqNtX+l9Jq2EeetSQI58RhCwUFRQGOpKaLEJ03JeZ5UjD3rTzm2HFr5P0SvQBYBsgLB9W1je3PPoD28Ro7IU=&longKey=AQ==

  • 0

Hmm it's always to debug without having it in front of you but I can try and point you in the right direction! :) If its working with smaller data samples it may be that you're [trying to encode an unsupported data type]/[base64 doesn't know what to encode so its sending invalid data] but I can't tell from the log there. The most common problem I find is that the data buffer is not being completely filled or filled correctly so I'd investigate that first! Enable tracing first, instructions here http://msdn.microsoft.com/en-us/library/ms733025.aspx :p then test and it will show you exactly where the problem is occurring. Hope this helps, good luck with the project mate!

  • 0

Writing the object to the body stream and changing the parameter type of the service to the complex object instead of a string made it work for some reason. REST is more of a pain learning how to use then SOAP that is for sure :)

  • 0

So I want to take this time to thank everyone who helped me. You guys are all great assets to this community and I hope I can give back one day by finding other questions I can answer in this forum and post my 2 cents on the subject (you guys are just too quick it seems most of the time and say what I would say :) ). +1 to you all and I hope you have a good holiday.

This topic is now closed to further replies.
  • Posts

    • This was cool back in the day when done properly - loved having icons of specific devices.
    • Microsoft quietly burying a massive Windows 7 hardware driver feature as Windows 11 kills it by Sayan Sen Last month Microsoft announced a big update for Windows hardware drivers. The company declared that it was killing Windows Device metadata and the Windows Metadata and Internet Services (WMIS). For those wondering what it is, device metadata, as the name suggests, is the collection of additional, user-facing information that an original equipment manufacturer (OEM) provides about a hardware device. The feature was introduced with Windows 7 and can include stuff like icons, logos, descriptive texts, among other things, that help the Windows UI display details about such devices in places like Task Manager or Device Manager. This was a huge deal back in the day when Windows 7 debuted. The company called the feature "Device Stage" and Microsoft described it as a "new visual interface" that essentially worked like a "multi-function version of Autoplay where it displays all the applications, services, and information related to your device." It is often considered synonymous with the Windows "Devices and Printers" Control Panel applet. Neowin did an in-depth overview of the feature when it first launched which you can find in its dedicated article here. The Windows OS was able to obtain the device experience metadata from the WMIS, but now that the feature is being deprecated, Microsoft has begun removing information about Device Stage from its official support documents. Neowin noticed while browsing that a support article regarding automatic Windows hardware drivers was updated for Windows 11 and 10 sometime last year after the release of Windows 11 24H2. Previously, this article was geared for Windows 7 and was much longer. It also contained information about Device Stage, which, as mentioned above, was a headlining feature on Windows 7. In the said article, the section "If Windows can't find information about your device in Device Stage" has been deleted. You can find the archived version of the support page here. Aside from shortening the amount of information on the page, Microsoft has also added some more details on it. The company has now tried to define what the Microsoft Basic Display Adapter is, how updating drivers through Device Manager works, as well as a thorough and detailed troubleshooting section for common hardware driver errors on Windows, including one for USB-C. You can find all the new details on the updated support page here on Microsoft's website.
    • Sounds creepy to say the least. Don't need nor want AI having access to my history. They're claiming it to be an "offline" model now, but how can we guarantee they don't go behind our backs and change that?
    • Exactly! Without those fundamentals you've mentioned, Democracy is literally just Demonstration of Crazy, nothing to be proud of in such system.
    • Still I see almost no ads in mobile Edge unlike Chrome. So their browser is much better at blocking ads than Chrome and it is a fact. It even blocks ads on YouTube and you can add simple custom block filters. Also, Edge still support manifest v2 on desktop, so I'll look for another browser when I start seeing ads again.
  • Recent Achievements

    • First Post
      viraltui earned a badge
      First Post
    • Reacting Well
      viraltui earned a badge
      Reacting Well
    • Week One Done
      LunaFerret earned a badge
      Week One Done
    • Week One Done
      Ricky Chan earned a badge
      Week One Done
    • Week One Done
      maimutza earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      481
    2. 2
      +FloatingFatMan
      264
    3. 3
      snowy owl
      238
    4. 4
      ATLien_0
      234
    5. 5
      Edouard
      176
  • Tell a friend

    Love Neowin? Tell a friend!