Difference between having an empty trailer and None

[peter-jerry-ye]

I have a possibly naive question since I'm not very familiar with HTTP.

Is there a necessity to define option<trailers> and option<future<trailers>>? What's the difference of having some empty trailers and having none?

[pavelsavara]

cc @dicej

[dicej]

I assume this question refers to

wasi-http/wit-0.3.0-draft/types.wit

Lines 246 to 271 in f45069d

	/// Represents an HTTP Request or Response's Body.
	///
	/// A body has both its contents - a stream of bytes - and a (possibly empty)
	/// set of trailers, indicating that the full contents of the body have been
	/// received. This resource represents the contents as a `stream<u8>` and the
	/// delivery of trailers as a `trailers`, and ensures that the user of this
	/// interface may only be consuming either the body contents or waiting on
	/// trailers at any given time.
	resource body {
	/// Construct a new `body` with the specified stream and trailers.
	constructor(
	%stream: stream<u8>,
	trailers: option<future<trailers>>
	);
	/// Returns the contents of the body, as a stream of bytes.
	///
	/// This function may be called multiple times as long as any `stream`s
	/// returned by previous calls have been dropped first.
	%stream: func() -> result<stream<u8>>;
	/// Takes ownership of `body`, and returns a `trailers`. This function will
	/// trap if a `stream` child is still alive.
	finish: static func(this: body) -> result<option<trailers>, error-code>;
	}

, correct?

We arrived at that API as part of the discussion in #101. IIRC, the idea was to use option<future<trailers>> as a parameter to the body constructor so you could easily pass none rather than have to create a new future whose only purpose is to resolve to empty trailers, given that most applications probably won't use trailers at all. I.e. it's an ergonomic and (slight) performance optimization, but in practice there should be no difference between passing some empty trailers and passing none.

I'm having trouble remembering why the finish function returns option<trailers> instead of option<future<trailers>>. I think the idea was that you'd only call finish after reading the body stream to the end, and the implementation would implicitly read any trailers as part of that process, storing them in a field and making them available immediately once finish is called. That would imply that you could only read the trailers after explicitly draining the stream, and I don't remember if that was the intention or not. @lukewagner do you happen remember? I'm not finding an answer in the original discussion.

[peter-jerry-ye]

@dicej Thank you for you explanation. I was asking about the APIs for outgoingbody/body for both wit 0.2.0 and 0.3.0-draft.

but in practice there should be no difference between passing some empty trailers and passing none.

That's what I'd like to confirm. Thank you.