Document concurrent instance reuse in wasi:http/service

proposals/http/wit-0.3.0-draft/worlds.wit

@@ -31,6 +31,38 @@ world service {
   ///
   /// This may also be used to receive synthesized or forwarded requests from
   /// another component.
+  ///
+  /// # Concurrent instance reuse
+  ///
+  /// Hosts may concurrently invoke this `handler` interface multiple times,
+  /// even when previous requests have yet to finish processing. This means that
+  /// the guest, if it becomes idle while being blocked on I/O, may be required
+  /// to service multiple requests at the same time. Guests can opt-out of
+  /// this behavior with component-model backpressure to avoid sending more
+  /// requests to this instance while a previous one is being processed,
+  /// however.
+  ///
+  /// In some contexts, correct attribution of resource usage and I/O operations
+  /// is an important requirement. For example, correct implementation of the
+  /// CDN-Loop header in the context of a proxy server requires that outgoing
+  /// HTTP requests can be attributed to the incoming HTTP request that induced
+  /// them.
+  ///
+  /// Hosts with this requirement must associate work happening on the same
+  /// component model task that the `handler` was originally invoked on with the
+  /// same incoming HTTP request.
+  ///
+  /// Conversely, guests must ensure that calls to imported interfaces happen on
+  /// the same component model task that the `handler` was originally invoked
+  /// on. Guest runtime implementations that do not provide this guarantee are
+  /// expected to opt-out of concurrent through the component model's
+  /// backpressure mechanisms.
+  ///
+  /// Note that hosts can't rely on this guarantee being upheld by all guests,
+  /// and shouldn't treat it as part of their security model. Instead, the
+  /// combination of the above host and guest requirements enable hosts to
+  /// enforce correctness properties on behalf of the overall system a guest is
+  /// part of.
   export handler;
 }