The HyBi IETF WG has picked up recently and it looks to be moving this to RFC. Chrome, Firefox, and many libraries support this extension. Given the widespread use of text-based messages for content, compression has an opportunity for giving up-to 75% reduction in payload size. The latest draft was just published two days ago.
I think this just got a thumbs up on its way to publication (if i'm reading the email correctly): https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/
:+1:
It is not possible to fully implement the specification on Android/with Java. This is the case because the Android/Java API doesn't offer the possibility to set the window bits of the Inflater/Deflater. Further the required SYNC_FLUSH option is not supported in Java until Java 7 and on Android until API Level 19 (as @swankjesse pointed out in the Okio source). Although the option can be used since Android 2.3.
Not a big fan of that spec. Seems like a lot more machinery than should be necessary. I think we'll be able to implement enough of the spec to be useful!
Is this still on the radar? The spec is an RFC now... https://tools.ietf.org/html/rfc7692. Would love to see this in okhttp.
Any news? BTW nv-websocket-client support this spec.
https://github.com/TakahikoKawasaki/nv-websocket-client
At this time we don't have plans to implement.
On Sun, Sep 18, 2016, 12:11 PM Yu-Hsuan Lin [email protected]
wrote:
Any news? BTW nv-websocket-client support this spec.
https://github.com/TakahikoKawasaki/nv-websocket-client—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/1733#issuecomment-247856662, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEVmYxzZ8nf-pPIm_vkYek-KeoD6eks5qrWLAgaJpZM4FNWTi
.
@JakeWharton any updates on implementing the extension?
No plans to. Feel free to send a PR
On Wed, Aug 1, 2018, 3:17 PM monil1334 notifications@github.com wrote:
@JakeWharton https://github.com/JakeWharton any updates on implementing
the extension?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/1733#issuecomment-409689335, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEbNV1H0I9Y0v9mzv8uJxNxHV1aRBks5uMf7fgaJpZM4FNWTi
.
Just confirmed that this interops nicely with the NodeJS Web Sockets library. That library has many tuning parameters; OkHttp currently has none. But their defaults are reassuring; both chose 1024 as the threshold to trigger compression.
https://github.com/square/okhttp/pull/5839
https://github.com/square/okhttp/pull/5848
https://github.com/square/okhttp/pull/5851
https://github.com/square/okhttp/pull/5867
https://github.com/square/okhttp/pull/5869
https://github.com/square/okhttp/pull/5871
Huge thanks to @AntonRutkevich for pushing this forward!
Thanks @swankjesse for the implementation!
With your deep OkHttp understanding, it's much cleaner and simpler than the original one.
Most helpful comment
Is this still on the radar? The spec is an RFC now... https://tools.ietf.org/html/rfc7692. Would love to see this in okhttp.