Re: [amqp-comment] amqp over http draft

[Alan Conway <aconway@redhat.com>]

On Tue, May 28, 2019 at 12:46 PM Gordon Sim <gsim@redhat.com> wrote:

On 28/05/2019 2:42 pm, Clemens Vasters wrote:
> 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.

That is better than the current draft in my opinion.

Seconded, but still bit unsure on the MUST for that property.

Think about it from the viewpoint of someone creating an AMQP request that is destined for an HTTP service. They follow normal AMQP request rules (set reply-to) and some extra HTTP-mapping rules (subject = HTTP method, can set HTTP headers as app-props) which is fine. However it makes little sense to invent an HTTP version string for a message that is not being sent over HTTP.

There are 2 major cases to cover here: AMQP semantics over HTTP (requires bilingual components) and bridging between "dumb" HTTP-only and AMQP-only clients, servers and networks.

Earlier Clemens said:

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.

Exactly - in the bridging case the AMQP network sees these as regular AMQP messages and routes accordingly. Bridges at the edges handle all the translation, and they can always infer (from some combination of to, reply-to, correlation-id) whether to treat the message as a request or a response without depending on the subject. (In my bridge a mismatch between subject and inferred message type would be an error, e.g. a request with an invalid method or a response with an invalid status code - but the subject is not used to decide the matter.)

So I'm ok with an app-prop, would prefer it be optional, can live with the requirement to set a "magic" property to the string "1.1" although I would allow entities that can infer it to accept messages without it.

Side note: can it be http:request, http:response? Abbreviations are harder to remember (was it resp, res or rsp?) and as for saving bytes, I fear that ship has sailed.