RE: [amqp-comment] amqp over http draft

[Clemens Vasters <clemensv@microsoft.com>]

Ok. Your use-case appears to be a pure passthrough scenario and your infra doesn't even seem to care about understanding what's in the subject, at all. 
 
I am specifically concerned about dispatching the request and response to a handler, i.e. your "then they know" aspect. I'm trying to figure out how specifically they can know from an arriving message stream.

Scenario:
a) one set of paired links forming a bi-directional channel
b) an HTTP service at each end, forming a "dialog" or "callback" interface. 
c) the services have an ongoing bi-directional conversation, each acting towards the other as client. That's not at all outlandish in IoT.
d) the "client" service also sends telemetry events multiplexed with requests

Here, I need to triage HTTP requests and HTTP responses at the endpoints to the right correlators and then handlers and also have messages that are one-way telemetry data that I want to dispatch elsewhere.

The HTTP request line and the HTTP status line give me that information, because I can infer from content and shape which of the two I'm looking at, but you seem to argue that having the same information in the AMQP subject field, with simpler encoding, is too clunky.

My alternate proposal would look like this, and turns "http:version" into a required "http:req" or "http:res" property. 

4.1.1	Request Line
The HTTP request-line contains the HTTP method, the request-target, and the HTTP version. 
*	HTTP method MUST be set in the properties section, subject field. 
*	HTTP request-target value MUST be URI-decoded and set in the properties section, to field.
*	The version value MUST be set in application-properties section, as value of the âhttp:reqâ string property. 
4.1.2	Status Line
The HTTP status-line contains the HTTP version, the status code, and the reason phrase. 
*	The version value MUST be set in application-properties section, as value of the âhttp:rspâ string property.
*	HTTP status code MUST be set in the properties section, subject field. 
*	HTTP reason phrase is OPTIONAL. The value is set in application-properties section, as value of the âhttp:reasonâ string property. The property SHOULD be omitted because RFC7230 3.1.2 RECOMMENDS it being ignored by clients.

-----Original Message-----
From: Gordon Sim <gsim@redhat.com> 
Sent: Dienstag, 28. Mai 2019 14:33
To: Clemens Vasters <clemensv@microsoft.com>; amqp-comment@lists.oasis-open.org
Subject: Re: [amqp-comment] amqp over http draft

On 28/05/2019 12:55 pm, Clemens Vasters wrote:
> I want "subject" to state "This is an HTTP PROPPATCH request" or "This is an HTTP 429 response" in trivially machine-readable form and as a singular statement.
> 
> You prefer for the subject to just say "PROPPATCH" or "429" and then gather further surrounding evidence from the message to figure out that this is indeed meant to be an HTTP request or response.

In my cases, the handling of messages is determined mostly by the link it arrives over and/or the 'to' field. A clean mapping means the status or method needs no special processing while bridging.

Once it gets to the intended recipient, they then know also what the subject implies, i.e. what PROPPATCH means if they support it, or whether the 429 response requires any action on their part. I can't envisage any case where the prefixes are useful, they just seem like ugly cruft that the applications (as well as other infrastructure) are forced to deal with.

> I fail to see how the latter is easier or involving fewer operations for someone writing a dispatcher or for someone looking at the message in a Wireshark dump or in a debugger.

It is clear I don't understand your use case at all, so I won't comment on that, but in my case it is certainly a hindrance not a help. Not only would it require unnecessary processing of the method and status in the bridging components, it would force amqp clients and services to use the prefixes when requesting or responding.

I don't really see any advantage to someone looking at a wireshark dump either tbh, and I've done my fair share of that.