Re: [amqp-comment] amqp over http draft

Inline: ClemensV>

Von: Gordon Sim <gsim@redhat.com>
Gesendet: Freitag, Mai 24, 2019 6:14 PM
An: amqp-comment@lists.oasis-open.org
Betreff: Re: [amqp-comment] amqp over http draft

On 24/05/2019 12:47 pm, Clemens Vasters wrote:
> When I have a multiplexing endpoint that accepts regular messages for one-way flows and that also responds to HTTP requests, I know that I have an HTTP request only when the HTTP request tells me that it is one.

Why do you need to know it is an HTTP request? You know it is a GET or a
POST, PUT, DELETE or whatever from the subject. You know the target. You
have all the headers. What would you do differently based on having an
indication of it being HTTP?

ClemensV> I need to know whether it’s an HTTP request if I have a generic framework that routes HTTP requests to a particular kind of handler while routing other messages elsewhere. Since HTTP methods are largely free-form strings (with a few well-known ones), there’s nothing I can anchor that generic dispatcher on other than a clear indicator that the request is an HTTP request. Also, AMQP is symmetric and therefore a link-pair (see the new link pairing spec) might carry requests and responses in both directions of a link pair and we’ve discussed that possibility in the F2F. Therefore it’s rather useful to be able to tell without guessing whether the message ought to go to the request dispatcher to the reply dispatcher. “Guessing” would involve inspecting the subject and the inferring whether it’s a method or a status code. Methods are tokens and tokens permit digits. “200” is valid method name https://tools.ietf.org/html/rfc7230#section-3.2.6. I understand that the scenario is far fetched, but I need to work with the existing framework and cover the corner cases.

> You appear to be advocating for my application having to use all sorts of hints to infer for a message to be an HTTP request, and the design in place makes a clear statement about it.

I'm advocating against munging it in with the method or status. AMQP
already has one of the most complex type systems around, and a rich
message format that uses it.

In the use case where an AMQP client makes a request it isn't
originating in HTTP . It might be ultimately handled by an HTTP service
or it might be handled by an AMQP service. The seamntics of the request
are clear and complete regardless.

ClemensV> the subject contains the HTTP status or request line, with the URI field of the request line already broken out into “to”. It is a straight mapping, no munging. I also disagree with the assumption that the client request is not “originating in HTTP”. I have a prototype here that makes the regular .NET HttpClient abstraction speak this binding and to the app it’s just HTTP. I also have an extension to ASP.NET that I can plug in as an alternate transport and that just looks like a web server. The transport here is as much HTTP as HTTP/2 or HTTP/3 are HTTP.

> If the core of your objection is about simplicity, I don't see how omitting a clear indicator is helping simplicity or how moving that indicator into a property that's aimed at the middleware layer will help simplicity.

I don't care about the indicator. I don't see any value in it. If you
have uses cases that need it, I would rather it is kept out of the
subject so that all the other cases that don't need it don't have to pay
the price for it anyway.

ClemensV> I strongly believe the indicator is needed and it needs to be part of the bare message so that it can be part of a message signature if there is one, and any alternative to putting it into subject makes matters more complicated than skipping exactly 9 characters to get to either method or status code.

--
This publicly archived list offers a means to provide input to the
OASIS Advanced Message Queuing Protocol (AMQP) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: amqp-comment-subscribe@lists.oasis-open.org
Unsubscribe: amqp-comment-unsubscribe@lists.oasis-open.org
List help: amqp-comment-help@lists.oasis-open.org
List archive: https://nam06.safelinks.protection.outlook.com/?url="">
Feedback License: https://nam06.safelinks.protection.outlook.com/?url="">
List Guidelines: https://nam06.safelinks.protection.outlook.com/?url="">
Committee: https://nam06.safelinks.protection.outlook.com/?url="">
Join OASIS: https://nam06.safelinks.protection.outlook.com/?url="">

amqp-comment message