3

I am trying to pass a base64 encoded string over WCF using WebHttpBinding.

I get the cryptic error 'Bad Request 400' that the server is not responding. I know its related to the size of the string because if I test a very short string (around 4KB or so) it works, but anything even slightly higher does not.

I've read everywhere that this is related to the maxReceivedMessageSize or other configuration in web.config for the binding, but even after changing those figures on both the client AND server I still get the error (in other words I have read alot of other posts about this exact problem but they didnt seem to help?)

Ive confirmed that everything is working properly up to the last line of the following code where the error is thrown:

static IHttpDataPush push = new HttpDataPush();

var wcfClient = ChannelHelperExtensions.WebHttpChannel<IHttpDataRcv>("http://localhost:3941/HttpRcv");

        var args = wcfClient.OptionArgs();

        foreach (var v in args)
        {
            HttpTransactionDataArgs uid = push.Option(v.Entity, v.Option, v.Key);

            wcfClient.ResponseNotification(uid); <-- error thrown at this line

These are my service contracts / data contracts:

[ServiceContract]
public interface IHttpDataPush
{
    [OperationContract]
    HttpTransactionDataArgs DbRequest(HttpTransactionOptionArgs args);

    [OperationContract]
    [WebGet]
    HttpTransactionDataArgs DbOption(string entity, string option, string key);
}

[DataContract]
[KnownType(typeof(HttpTransactionDataArgs))]
public class HttpTransactionDataArgs
{
    [DataMember]
    public string EntityName { get; set; }

    [DataMember]
    public string Base64Schema { get; set; }

    [DataMember]
    public string Base64Data { get; set; }

    [DataMember]
    public bool TransactionSuccessful { get; set; }
}

Contracts for the receiving end of the data push:

[ServiceContract]
public interface IHttpDataRcv
{
    [OperationContract]
    HttpTransactionOptionArgs[] OptionArgs();

    [OperationContract]
    bool ResponseNotification(HttpTransactionDataArgs args);
}

[DataContract]
[KnownType(typeof(HttpTransactionOptionArgs))]
public class HttpTransactionOptionArgs
{
    [DataMember]
    public string Entity { get; set; }

    [DataMember]
    public string Option { get; set; }

    [DataMember]
    public string Key { get; set; }
}

Server-side web.config:

<bindings>
  <webHttpBinding>
    <binding name="webHttpConfig" closeTimeout="00:20:00" openTimeout="00:20:00"
        receiveTimeout="00:20:00" sendTimeout="00:20:00"
        maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" >
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
          maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
    </binding>

<endpoint address="/HttpRcv" behaviorConfiguration="REST" bindingConfiguration="webHttpConfig" binding="webHttpBinding" contract="EmailContracts.IHttpDataRvc" />

Client-side web config (where the error is thrown:)

<client>
  <endpoint address="http://localhost:3941/HttpRcv"
            binding="webHttpBinding"
            bindingConfiguration="webHttpConfig"
            contract="EmailContracts.IHttpDataRcv" />
</client>

    <bindings>
  <webHttpBinding>
    <binding name="webHttpConfig" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
      <readerQuotas maxStringContentLength="2147483647" maxArrayLength="2147483647" 
                    maxDepth="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
    </binding>      
  </webHttpBinding>
</bindings>
Sean Thoman
  • 7,429
  • 6
  • 56
  • 103
  • I don't know off hand, but if you set up tracing for the web service, it might lend some useful information on why the error was generated. – regex Jun 08 '11 at 23:24
  • I have tracing. Didnt see any obvious errors pop up but I'm not too keen on how to navigate the trace log, yet. Ill look into it further. – Sean Thoman Jun 08 '11 at 23:27

1 Answers1

1

Are you hosting in IIS/ASP.NET? If so you must also increase their settings as well.

For IIS7 you want to change the system.webServer/security/requestFiltering/requestLimits/@maxAllowedContentLength.

For ASP.NET you want to change the system.web/httpRuntime/@maxRequestLength.

Drew Marsh
  • 33,111
  • 3
  • 82
  • 100
  • This is all in visual studio, using local dev server. – Sean Thoman Jun 09 '11 at 08:45
  • Did you try setting them? The httpRuntime one will affect the Cassini dev server as well. That said, at some point you will deploy this to IIS right? So you should get the system.webServer one in there too. – Drew Marsh Jun 09 '11 at 14:24
  • 1
    I did increase the httpRuntime maxRequestLength, still get the same error though. – Sean Thoman Jun 09 '11 at 16:33
  • Ok, have you enabled WCF tracing to see if WCF is even being reached? If it's not you know it's the HTTP level that's rejecting the request. Can you change to use IIS or IISExpress to test? – Drew Marsh Jun 09 '11 at 17:57
  • My trace log is working and definitely shows most errors, however this error doesnt produce an error in the trace log on the server side (maybe theres something on the client side going on?). The only thing I see on the server side traces is a bunch of 'Construct ServiceHost' and 'ASP.net hosted service activated messages'. No error in the trace log server side. Also this is a slightly unusual situation in that the client is actually trying to PUSH the large dataset to the server, if you notice. Maybe that needs to be considered? Its not the usual client pulling data from server. – Sean Thoman Jun 09 '11 at 18:28
  • Actually on second thought I think I found an error server side: System.ServiceModel.ProtocolException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element – Sean Thoman Jun 09 '11 at 18:39
  • Well there ya go. So somehow the binding you listed isn't actually being applied to your service. – Drew Marsh Jun 09 '11 at 21:30