Gzip Request Body?

[Trollkarl]

Hi,

I understand that I can get compressed data back from the API but is it also possible to compress request bodies too?

I have attempted to send a gzip compressed request to the JSON RPC placeOrders endpoint but I get back a 400 Bad Request. I am setting the Content-Encoding header and (I believe) correctly gzipping the data iteself.

[jabe]

What language are you coding in? I'm using VB.NET and after several tries succeeded with

request.Headers.Add("Content-Encoding: gzip")

[LiamP]

What language are you coding in? I'm using VB.NET and after several tries succeeded with

request.Headers.Add("Content-Encoding: gzip")

Never tried this, did you find it quicker?

[jabe]

Never tried this, did you find it quicker?

I don't recall it making much difference, but It's ages since I did it. I did add code into my program to accumulate the size of data returned with each call to get an idea about overheads and, as far as I can recall, it would have downloaded maybe 10-12MB on set up and maybe as much again if I left it running all day. As it was, I got it to save the initial data to file so I could restart it without it having to retrieve it all over again.

[Trollkarl]

I contacted BDP and this was their response:

>Thank you for getting in touch.
>
>Unfortunately the API does not support the data being gzipped.

(To be clear this is request data we are talking about)

So jabe I suspect you are setting the header but not actually gzipping the body - when I actually gzipped my request data I was getting 400 Bad Request so I think it is the case that the API doesn't support this.

[jabe]

I contacted BDP and this was their response:

>Thank you for getting in touch.
>
>Unfortunately the API does not support the data being gzipped.

(To be clear this is request data we are talking about)

So jabe I suspect you are setting the header but not actually gzipping the body - when I actually gzipped my request data I was getting 400 Bad Request so I think it is the case that the API doesn't support this.

Thanks. I don't suppose any or many of my requests need zipping really.

[geoffw123]

Hi

Some thoughts, this is all off the top of my head, so no quarantees this is correct

1) Betfairs recommended practice is that your send packet contains the header "Content-Encoding: gzip", i,e you tell the server you can accept gzipped data back from them.

2) I am not even sure that it is possible to gzip the send packet as mentioned by the original poster. If you think about it, there is a protocol here where you tell the Server whether you can accept zipped data or not. For the send packet just assuming that the Server can figure out from an initial packet if it is gzipped or not would not make sense and not be following a similar protocol.

3) Betfair's recommended practice doesnt mention the send packet, so the implication is that it is not possible, or you dont need to do it. The send packets to BF are typically small anyways. Gzipping a small block of data I think can in some cases inflate the size, so would be pointless.

4) Is is worth the extra bit of complexity in the code to get BF to send data back to you in gzipped form ? I think it is yes, as it isnt that hard to implement and can save a fair chunk of bytes down the wires. Obviously the slower your connection speed is the better the saving would be.

Let me measure a couple of numbers to illustrate compression levels ............

Send packet size asking for all todays footy games = 700 bytes
The gzipped response packet back is 35,989 Bytes. This then gets decompressed to 262,585 Bytes (Ratio 7.3 )


Its worthwile doing on the Menu Navigation data too as that is a big old download
Send packet size asking for Saturdays Navigation data = 290 bytes
The gzipped response packet back is 184,090 Bytes. This then gets decompressed to 2,633,213, Bytes (Ratio 7.3 again )