One more note:
I see in another thread named "Http status code for soap fault" where
you write that errors changed to fault HTTP 500 instead of OK 200.
That most probably explains why we run into the problems just
recently, because the limitation in .NET is related just to fault
headers.

On Feb 18, 9:32 pm, Ales Sturala <stur...@gmail.com> wrote:
> Hello Eric,
> yes, I use Fiddler to track the communication between our application
> and AdWords that works like a proxy and moreover it uses its own
> certificate to get behind the SSL security, otherwise it is impossible
> to see the communication. I noticed now that there is a button for
> decoding the SOAP message, after using it the "fef" string was removed
> and the XML was well-formed. So the samples I posted here were not
> decoded yet, which means also that the problems must be somewhere
> else.
>
> I took another approach to get the raw soap headers. To keep it short,
> I found out that the soap message was not send complete, but was
> truncated. I checked the string that gets through and it is 65664
> characters, that means 64KB, which is already suspicious. I found 
> herehttp://forums.asp.net/t/1189121.aspxthat .NET trunactes SOAP error
> responses that are longer than 64KB. Unfortunately the Google library
> does not change this default value and therefore it fails. It can be
> changed easily in code or in config file:
>
>   <system.net>
>     <settings>
>       <httpWebRequest maximumErrorResponseLength="-1"  />
>     </settings>
>   </system.net>
>
> After I set up this in our application, everything works fine. I'll
> report this issue on the .NET AdWords API page.
>
> There is just one thing I don't understand, which is why this problem
> suddenly started to occur week ago and did not happen before...
>
> On Feb 18, 5:36 pm, AdWords API Advisor <adwordsapiadvi...@google.com>
> wrote:
>
> > Hi Ales,
>
> > Thanks for sending along the logs.  I talked with my colleagues, and
> > it appears that these extra characters are actually part of the
> > chunked transfer encoding spec:
>
> >  http://en.wikipedia.org/wiki/Chunked_encoding
>
> > The "fef" characters are actually the number of bytes in the next
> > chunk, and these values should be removed automatically.  The .NET Web
> > Services library supports a chunked transfer encoding, and in my own
> > tests the data is being parsed correctly.
>
> > Which version of the .NET client library are you using?
> > Are you using a proxy server, or some other interceptor that could be
> > passing along the chunked content incorrectly?
>
> > Best,
> > - Eric
>
> > On Feb 17, 3:14 am, Ales Sturala <stur...@gmail.com> wrote:
>
> > > Done
>
> > > On Feb 17, 1:10 am, AdWords API Advisor <adwordsapiadvi...@google.com>
> > > wrote:
>
> > > > Hi,
>
> > > > I looked up the logs for these requests, and the XML we have doesn't
> > > > include these extra characters.  Do you have the full SOAP XML logs
> > > > for this request?  If so, can you send them to
> > > > adwordsapiadvi...@google.com and then post a message to this thread so
> > > > I can retrieve them?
>
> > > > Thanks,
> > > > - Eric
>
> > > > On Feb 16, 3:47 pm, majco <martinusapiklie...@centrum.sk> wrote:
>
> > > > > I have big problem with this error.
> > > > > It happens to me often especially when insert around 3000 keywords
> > > > > together.
>
> > > > > You solve this problem?

-- 
You received this message because you are subscribed to the Google Groups 
"AdWords API Forum" group.
To post to this group, send email to adwords-...@googlegroups.com.
To unsubscribe from this group, send email to 
adwords-api+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/adwords-api?hl=en.

Reply via email to