Page MenuHomePhabricator

REST API Client Developer uses Gzip content encoding
Closed, DeclinedPublic


"As a Client Developer, I want to use Gzip content encoding in my HTTP responses, so my API calls are faster and require fewer network resources for my users."

The REST API infrastructure should support Gzip content coding in HTTP responses.

Ideally, this would be opaque to the REST handler code, or at least very easy to support.

Event Timeline

Since this will be embedded within MediaWiki, changes are we can reuse existing MediaWiki code for this.

See OutputHandler::handleGzip().

This probably makes more sense as a subtask of T221737: REST API Infrastructure in MediaWiki now.

eprodromou renamed this task from Handle Gzip encoding for all endpoint in Parsoid REST API to Client Developer uses Gzip content encoding.Nov 6 2019, 7:35 PM
eprodromou updated the task description. (Show Details)

Gzipped responses (Content-Encoding: gzip) are already handled by virtue of it using existing MediaWiki infrastructure. Note if testing locally you may have to configure PHP to have output_buffering = off for MediaWiki.

There's no HTTP standard for gzipped request bodies, as far as I know. Is there a standard?

Tgr renamed this task from Client Developer uses Gzip content encoding to REST API Client Developer uses Gzip content encoding.Nov 7 2019, 12:31 AM

There's no HTTP standard for gzipped request bodies, as far as I know. Is there a standard?

Apart of RFC2616 that states If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type). I'm not aware of any standard.

Also, it states Request and Response messages MAY transfer an entity if not otherwise restricted by the request method and Content-Encoding being listed as a option in entity-header

So, standard-wise, we are allowed to accept gzipped request bodies with content-encoding header. I'm not aware of any browsers that do it, but it seems like a cool feature to have for an API.

@Anomie when you say "already handled", do you mean that it happens automatically, without our handler classes having to call any specific code? Or do you mean there's already a service to use within MW that our handler classes need to call?

The handler classes don't have to do anything special. MediaWiki sets it up in wfWebStartSetup(), assuming PHP hasn't already started output buffering for some reason.

$ curl --compressed -v
*   Trying
* Connected to ( port 80 (#0)
> GET /w/rest.php/user/Anomie/hello HTTP/1.1
> Host:
> User-Agent: curl/7.66.0
> Accept: */*
> Accept-Encoding: deflate, gzip, br
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 08 Nov 2019 18:19:48 GMT
< Server: Apache/2.4.41 (Debian)
< X-Content-Type-Options: nosniff
< P3P: CP="This is not a P3P policy! See for more info."
< Content-Encoding: gzip
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: application/json
* Connection #0 to host left intact
{"message":"Hello, Anomie!"}

Note the response includes Content-Encoding: gzip.

Great. That looks good to me. I'll confirm locally and then close this ticket.

This functionality is already covered in MW and in the Varnish layer for WMF.