Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
  • drip-server-timing
  • compress-middleware
  • v2.11.0
  • v2.10.0
  • v2.9.2
  • v2.9.1
  • v2.9.0
  • v2.8.0
  • v2.7.0
  • v2.6.0
  • v2.5.6
  • v2.5.5
  • v2.5.4
  • v2.5.3
  • v2.5.2
  • v2.5.1
  • v2.5.0
  • v2.4.2
  • v2.4.1
  • v2.4.0
  • v2.3.0
  • v2.2.2
23 results

Makefile

Blame
    • Will McCutchen's avatar
      a6709422
      Improve /drip semantics (#132) · a6709422
      Will McCutchen authored
      This started with me wading into the `/drip` endpoint to add
      `Server-Timing` trailers as suggested in
      https://github.com/mccutchen/go-httpbin/issues/72.
      
      In making those changes, I discovered that the standard golang net/http
      server we're building on only supports sending trailers when the
      response is written using `Content-Encoding: chunked`. Initially, I
      thought it would be reasonable for this endpoint, which is designed to
      stream writes to the client, to switch over to a chunked response, but
      upon further consideration I don't think that's a good idea. So I'll
      defer adding trailers to some later work.
      
      But, in thinking this through (and fighting with the unit tests already
      in place for drip), I realized that the `/drip` endpoint had room for
      improvement, if we think about it as an endpoint _designed to let
      clients test their behavior when an HTTP server is responding very
      slowly_.
      
      So, we ended up with these changes:
      
      Initial delay semantics:
      - Originally, `/drip` would immediately write the desired status code
      and then wait for the initial delay (if any).
      - Here we update that so that it waits for the initial delay before
      writing anything to the response, to better simulate a server that is
      just very slow to respond at all.
      
      Incremental write timings:
      - Switch over to a ticker to more accurately pace the incremental writes
      across the requested duration
      - Stop sleeping after the final byte is written (should not affect
      clients, but avoids wasting server resources)
      
      Worth noting that I now believe it's important that this endpoint
      **not** switch over to chunked content encoding, because it is useful to
      maintain and endpoint that simulates a server very slowly writing a
      "normal" HTTP response.
      Improve /drip semantics (#132)
      Will McCutchen authored
      This started with me wading into the `/drip` endpoint to add
      `Server-Timing` trailers as suggested in
      https://github.com/mccutchen/go-httpbin/issues/72.
      
      In making those changes, I discovered that the standard golang net/http
      server we're building on only supports sending trailers when the
      response is written using `Content-Encoding: chunked`. Initially, I
      thought it would be reasonable for this endpoint, which is designed to
      stream writes to the client, to switch over to a chunked response, but
      upon further consideration I don't think that's a good idea. So I'll
      defer adding trailers to some later work.
      
      But, in thinking this through (and fighting with the unit tests already
      in place for drip), I realized that the `/drip` endpoint had room for
      improvement, if we think about it as an endpoint _designed to let
      clients test their behavior when an HTTP server is responding very
      slowly_.
      
      So, we ended up with these changes:
      
      Initial delay semantics:
      - Originally, `/drip` would immediately write the desired status code
      and then wait for the initial delay (if any).
      - Here we update that so that it waits for the initial delay before
      writing anything to the response, to better simulate a server that is
      just very slow to respond at all.
      
      Incremental write timings:
      - Switch over to a ticker to more accurately pace the incremental writes
      across the requested duration
      - Stop sleeping after the final byte is written (should not affect
      clients, but avoids wasting server resources)
      
      Worth noting that I now believe it's important that this endpoint
      **not** switch over to chunked content encoding, because it is useful to
      maintain and endpoint that simulates a server very slowly writing a
      "normal" HTTP response.