NetTalk Central

Author Topic: Incorect content length  (Read 3403 times)

Alberto

  • Hero Member
  • *****
  • Posts: 1873
    • MSN Messenger - alberto-michelis@hotmail.com
    • View Profile
    • ARMi software solutions
    • Email
Incorect content length
« on: May 23, 2017, 02:46:08 AM »
Hi, I have an NT server wich is readed ok by browsers and by NetWebClient procs.
Im trying to read it by an Android app, but it simpossible.
Asking the people who made the java code to read it, they say that the NT server is giving an incorrect content lenght and that I have to disable compression.

Is it possible thet the NT server return an oncorrect content length when compressing?

Thanks

You can test it here:
http://calc.futurobursatil.com.ar/xmloc?F=Sxml&S=&Z=1&ES=DICA,AUSO,CAPU,IRSA
-----------
Regards
Alberto

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Incorect content length
« Reply #1 on: May 23, 2017, 07:52:30 AM »
As far as I can see the value returned by your URL is correct.
the header says;

Content-Length: 574
Content-Encoding: gzip

The (decompressed) text is 2553 bytes long - and if I save that, and compress it, it comes to 574 bytes.

So, no, I don't think there's any problem in the server.

>> Asking the people who made the java code to read it, they say that the NT server is giving an incorrect content lenght and that I have to disable compression.

Ideally you don't want to disable compression for everyone, that would be very bad. If their client is unable to handle the compressed values though then I recommend they adjust their request header so that it does not include the header
Accept-Encoding: gzip
in the request.

So, in other words, they can disable compression on their side, and they do it by setting the header appropriately.

Cheers
Bruce