Error 500 - 'text/html'...expected 'text/xml' (string overflow?)

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jon - 07 Apr 2006 02:11 GMT

Anyone seen a webservice return this error:

Error: Client found response content type of 'text/html;charset=utf-8', but
expected 'text/xml'.
The request failed with the error message:
--Error 500:--

I'm hitting a web service which retuns XML data in a string. It works fine
for smaller requests (300K for example)

When I hit this web service and request all the data (~7M) I get that error
above. I only know it's approx. 7M because it use to work and only started
failing recently.

Is there a limit on the size of the string the webservice can return?

I also ran a TCP packet trace on a success vs a failure and what's
interesting is that the failure has way less packets ~35 compared to the
success with over 150.

Reply to this Message

Robert May - 10 Apr 2006 18:49 GMT

Jon,

Yes, I have seen this before and it was caused by the result being to large.
To fix it, I had to compress the results of the xml data I was passing. We
also set up a url where they could download it directly, instead of passing
the entire thing back in the web service.

We didn't ever report it to anyone, so I'm not sure if this is a bug,
desired behavior, or what.

Robert May

> Anyone seen a webservice return this error:
>
[quoted text clipped - 19 lines]
> interesting is that the failure has way less packets ~35 compared to the
> success with over 150.

Reply to this Message

Jon - 10 Apr 2006 19:03 GMT

Thanks Robert,

Does anyone know the limit on the size of the string the webservice can
return?
I suppose one way to resolve this would be to ask that the webservice
provider change the response type to a stream, but I've heard setting up a
stream in a webservice is a bit difficult.

Does anyone have experience with setting up stream responses for a webservice?

This is somewhat boogling to me beacause I thought webservices (SOAP) was
designed to transfer large amounts of XML data in an encrypted state.
Encrypting the data increases the size quite a bit. So, what's with the
difficultly actually implementing this?

Thanks!

> Jon,
>
[quoted text clipped - 30 lines]
> > interesting is that the failure has way less packets ~35 compared to the
> > success with over 150.

Reply to this Message

Error 500 - 'text/html'...expected 'text/xml' (string overflow?)

Free Magazines