Decoding a message sent by HTTP

  • Thread starter Thread starter stewart
  • Start date Start date
S

stewart

Hi group,

When an application makes an HTTP request it is sent back the
following -

;¸5‰c 7Vv¡f7Ÿ¼ó
ÃySZ‰Kk„¨'Ä€@©BDK¬bâëm Ólf;Nf7΋l½›Uò¼ò›
´©î!{?ñâMZ¤‰Ç9‹€›GÈ ©ðâ`x‹÷‡¬ØæÃïª|JP¼CÝ\jhÕN­ÒzÕ¾nŽÆºÔW‹ºùHÛ;
4÷Qa˜ŸöXZ»)4d¸d‹…Â…‰ZŒ(¡1DbC"çD€c8«DA3žŸiŽ`Ävn‰÷áYv

Any clues on what the encoding is or how to turn it into something
sensible? I believe that the included data is a collection of times
and prices.

Thanks.
 
When an application makes an HTTP request it is sent back the
following -

;¸5‰c 7Vv¡f7Ÿ¼ó
ÃySZ‰Kk„¨'Ä€@©BDK¬bâëm Ólf;Nf7΋l½›Uò¼ò›
´©î!{?ñâMZ¤‰Ç9‹€›GÈ ©ðâ`x‹÷‡¬ØæÃïª|JP¼CÝ\jhÕN­ÒzÕ¾nŽÆºÔW‹ºùHÛ;
4÷Qa˜ŸöXZ»)4d¸d‹…Â…‰ZŒ(¡1DbC"çD€c8«DA3žŸiŽ`Ävn‰÷áYv

Any clues on what the encoding is or how to turn it into something
sensible? I believe that the included data is a collection of times
and prices.
Click to expand...
You should have been supplied both encoding and type. Check the HTTP
Content-Type header. Without that header, guessing at what it might be is
pretty fruitless. It could be a compressed stream, and it could have been
further mangled before you posted it here, and once more by your mail
client, so at this point it would be pretty much impossible to say what it
is with any certainty. (At this point it's not a valid compressed stream,
for what it's worth.)

For better results, use wget or a similar raw client (or a traffic analyzer
like Fiddler or Wireshark) and watch the output before your client tries to
decode it.
 
Thanks for your thoughts. The text pasted was actually received in my
web browser. Below are the details as captured by WireShark.

Hypertext Transfer Protocol
HTTP/1.1 200 OK\n
Connection: Keep-Alive\r\n
Content-length: 208\r\n
Date: Tue, 17 Mar 2009 15:21:46 GMT\r\n
Content-Type: text/plain\n
 
Hi group,

When an application makes an HTTP request it is sent back the
following -

; ¸5 ‰c       7Vv¡f7Ÿ ¼ó
ÃySZ‰Kk „¨' Ä€ @©BDK¬bâëm  Ólf; Nf7΋l½›Uò¼ò›
´©î!{?ñâMZ¤‰Ç9‹€ ›GÈ      ©ðâ`x‹÷‡¬ØæÃïª|JP ¼CÝ\jhÕ N­Ò zÕ¾n ŽÆºÔW‹ºùHÛ;
4÷Qa˜ŸöXZ»)  4d¸d‹ …Â…‰ ZŒ(¡ 1DbC"çD€c8 «DA 3ž ŸiŽ` Ävn ‰÷ áYv  

Any clues on what the encoding is or how to turn it into something
sensible?  I believe that the included data is a collection of times
and prices.

Thanks.
Click to expand...

I suppose this is a binary octet stream, sometimes incorrectly
configured Apache servers responses by sending data on a text request
 
Thanks for your thoughts. The text pasted was actually received in my
web browser. Below are the details as captured by WireShark.

Hypertext Transfer Protocol
HTTP/1.1 200 OK\n
Connection: Keep-Alive\r\n
Content-length: 208\r\n
Date: Tue, 17 Mar 2009 15:21:46 GMT\r\n
Content-Type: text/plain\n
Click to expand...

Well, that's quite obviously wrong. Good luck figuring out what the actual
content type is...
 
I have once written a service that broadcasted on http: port 80 and 8080
over the web , however the service was only intended for my client
applications
what i did was sending all sorts of data ( text , pictures and other
binaries ) but i did not want that anny other program could do anything with
the data stream except my own clients .

so i created a custom XML envelope , wrote in text or my encodebase64 data
of the picture or other binary in the data field in that envelope then
perfomed
my own text hash , then G-Zipped the whole string as this is a standard
that all proxies / gateways support and it acually made my transfers much
faster
and only then send it as a "normall" response to my clients .

As my clients knew exactly what to do with the response stream this was a
perfect solution to keep the Riffraff out of my valuable data , as in my
situation the value of the prog was in the transfered data and no https was
economical not an option at that time :-) .

So i guess you have just encountered a simular piece of code :-) , cause if
it was the idea that you could process the data you can just ask the
developer of the
response server how to interprete his data .

My first guess would be to see if the data you receive is Gzipped , however
then you could be in for another surprise :-) ( i used a custom bit shift
algorythm )



regards

Michel
 
Back
Top