I am trying to decode the data from a winpcap file, I have uploaded it on the link please help me.
I tried everything but it seems I am unable to decode the response data to readable digits.
http://pcapperf.appspot.com/view?hash_str=0ba390ad10bd162ec264ec083b1a7fd1
Related
I am trying to call /vision/v3.1/read/analyze API with a PDF, but sending Content-Type header as application/pdf or application/octet-stream is giving an InvalidImage error. What should be the header value ? Any code sample that I can refer to ?
The supported Content-Types are application/json- analyze images from URL and application/octet-stream - analyze images from disk. I tried the Read API reference and provided url for a pdf file. Confirmed using Get Read Result and works fine. Check out available code samples in python, tutorial and c#, tutorial.
I have difficulty in understanding how this header works.
Briefly my question is
If i am requesting a post to certain resource then let's
Say in 1st case response is some json string and in 2nd case response is a .jar file.
1.Should client include accept-header:gzip,deflate in both cases while sending HTTP request,knowing that first one results in json string?
2.What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems?
3.what happens if i include accept-encoding:gzip in first case where json string is received. So i receive a zipped data as my response(i am not even sure if get zipped data or some encoded data as response.I think zipped data means something zipped like .jar/.zip and encoded data means Encoded data of the original data ,which one is happening zipping or encoding)?
4.Lets say the server sends the response with Contentype header as "application/octet-stream". Now is it must to use accept-header:gzip,deflate
A client can use Accept-Encoding HTTP request header to tell the server that it can accept a compressed response.
The server can use the request header to decide if it should send a compressed response or not. It can ignore the header and always send a non-compressed response (possibly less efficient). It can ignore the header and always send a compressed response (risking giving a client a response it can't decode).
Should client include accept-header:gzip,deflate in both cases
I can't think of any reason to not tell the server that a client can handle a compressed response (assuming that fact is true).
What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems
It might be a waste of processor power for little or no saving in bytes.
That's not a reason for the client to say it can't handle a compressed response though. That's a decision to be made on the server.
what happens if i include accept-encoding:gzip in first case where json string is received.
Then the client has told the server that a compressed response is acceptable.
So i receive a zipped data as my response
The server might send a compressed response. It might ignore the header.
i am not even sure if get zipped data or some encoded data as response
There isn't an "or" here.
The data is encoded using a compression algorithm.
Lets say the server sends the response with Contentype header as "application/octet-stream"
That just means the server doesn't know what type of data it is sending. Instead of saying "This is JSON" or "This is a jar file" it is saying "I dunno what this is, it's just a stream of bytes to me".
Now is it must to use accept-header:gzip,deflate
It doesn't make a difference.
The server can compress the data. It can send uncompressed data. It can use the Accept-Encoding request header to decide which of the two.
Yes, why not? If the JSON payload is big, compressing it will make a lot of sense.
It's just overhead.
You might receive gzipped data - not a ZIP file. You may want to read RFCs 7230 and RFC 7231 for details.
The internet media type of the payload is completely independent of the content coding.
Hi Guys Im currently capturing some traffic from an android application, but the requests it is sending out to server seems encrypted. Would you guys know how to decrypt such requests? Or is that impossible to do?
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=%5b%7b%22id%22%3a177205%2c%22time%22%3a1485552512601%2c%22name%22%3a%22collectResource%22%2c%22params%22%3a%5b155%5d%2c%22hash%22%3a1948904473%7d%5d&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
That's not encrypted, it's encoded. Do a search for "online url decode". In your example you will get:
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=[{"id":177205,"time":1485552512601,"name":"collectResource","params":[155],"hash":1948904473}]&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
The %xx are url encoded hex values. For example %22 is the hex version of the double quote character. I think that if you use javascript or other tool to decode the url encoding or manually change all % strings to the equivalent characters, you will see that the message is really just url encoded plain text.
I get some string data from a webservice in utf-8. How do I convert it in an aspx vb to a readable format? The website is german.
UTF-8 is readable. ASP.NET should be able to read it just fine. If it's transmitted with a Content-Type whose charset parameter is set to something other than UTF-8 you might need to instruct ASP.NET to force the decoding to UTF-8. Use Fiddler and figure out how the HTTP request looks like and pay special attention to the Content-Type parameter.
If you have a different output-encoding than UTF-8, you should still be able to output the characters correctly if you decode them with the correct encoding. What is your output encoding? What encoding is the web service you're communicating with using? Figure the answer to these questions (using Fiddler) and your solution should be obvious.
I am writing client software that initiates a HTTP request with a large blob of text (JSON object actually) as POST parameter. I want to compress this text before sending and decompress the text on the server.
Gzip produces binary, which I can't send as a POST parameter, I think.
Which options/algorithms exist to compress text and send it to a web server?
Edit: Would it be an option to GZIP and then BASE64 encode the binary data?
Why don't you just use the standard HTTP gzip compression?
(It just seems a bit mad to needlessly re-invent the wheel.)
Update
Ah yes - my bad. So why not simply gzip the file, upload it to the server as you would a multipart/form-data file upload and then un-gzip it on the server?
The file is a long/unnecessary work around, the original question relates to battle with unbearably large Json blob. From my hacking around I can tell it highly depends on the server, some do support it some don't.
To the original question, you can set the binary data in http post, the real question what is the server going to do with it. It is the same way that C# client does not automatically unzip, you have to write extra code.