x/net/http2: add push_promise frame support

[bradfitz]

This bug is about http2 support for PUSH_PROMISE frames, letting http.Handlers push their own streams to clients.

Previously:
bradfitz/http2#23
bradfitz/http2#34

Let's do this first in x/net/http2 and only add API to the standard library after it's baked long enough in x/net.

[bradfitz]

/cc @DanielMorsing @brk0v @bmizerany @ncdc

[ncdc]

@bradfitz thanks for the cc. I'm actually interested in being able to create streams in the client (e.g. something like c := conn.Hijack(); s := c.createStream(...). I don't want to steal the purpose of this issue - should we create a new one for that?

cc @lavalamp @thockin @smarterclayton

[bradfitz]

Sure, create a new bug (I think). I don't exactly understand.

[DanielMorsing]

I think the Pusher interface way of doing this that I put in the first CL is good and we can probably reuse it.

Do we want to do anything smart with the headers we send with the push_promise? Things like cookies and which type of element the resource appears in, changes how browsers request it.

[banks]

One motivator for integrating Push into http.Handler is that the draft Web Push protocol uses it.

Go is generally a great candidate for writing these new standards-based push backends and I'm already considering it for one open source real-time project in centrifugal/centrifugo#62.

I imagine (but have not yet got past reading docs/source) that the support for the frames in http2 would make it possible to manually implement by hijacking the http conn, but this is a much higher barrier to writing a conforming service/library.

[tombergan]

Just found this issue. This is a feature I would love to see make it into x/net/http2. I recently needed to do some local testing with HTTP/2 push, so I implemented push using a design that happened to be roughly similar to bradfitz/http2#23, but instead of adding a Push method to the H2 ResponseWriter, I added an H2Stream method to the ResponseWriter that returns a handle that exposes various H2-specific features:

func (*h2responseWriter) H2Stream() H2Stream { ... }

type H2Stream struct { ... }

// Push sends a push promise frame and dispatches a pseudo-request to the Server's handler.
// Note that method must be GET or HEAD according to the spec (see Section 8.2).
// Returns the StreamID of the pushed response.
func (H2Stream) Push(method, url string, h http.Header) (uint32, error) { ... }

// StreamID returns the unique identifier of this stream, per spec Section 5.1.1.
func (H2Stream) StreamID() uint32 { ... }

// Other methods could be added, such as:
func (H2Stream) SetPriority(dependency uint32, weight uint8) error { ... }

If adding a method to the ResponseWriter is too magical, another design is to add an H2-specific handler function to the http2.Server object where the signature is:

package http2
type Server struct {
  ...
  // if not specified, defaults to a wrapper around the http.Server.Handler passed to ConfigureServer
  Handler func(H2Stream, ResponseWriter, *Request)
}

Implementation note: I believe the code at bradfitz/http2#23 misses a subtlety in the spec. Section 5.1.1 says "The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved." This implies that push promise frames MUST be written to the wire in promised-id-order -- this requires some changes to http2/writesched.go.

I'm happy to do the leg work of the implementation, if needed, once we reach consensus on a design.

Do we want to do anything smart with the headers we send with the push_promise? Things like cookies and which type of element the resource appears in, changes how browsers request it.

My opinion is an emphatic no. If the caller does not specify any request headers, the push promise frame should not include any headers (other than the standard psuedo-headers like ":path", etc.). For example, it's impossible in general to know if the cookies on the initial request apply to the specific path of the url being pushed -- this is something that will be specific to each cookie and each server.

[yonderblue]

Milestone?

[ianlancetaylor]

Setting to 1.8 to see if somebody wants to work on it.