[openpgp] Re: HKP draft TODO items

--===============4627953584640691665==
Content-Type: multipart/alternative; boundary="000000000000f48d1c06528f7b7b"

--000000000000f48d1c06528f7b7b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Heiko,

Yes, that is a fair concern. I do not think we should make the 400 behavior
a hard requirement if that would make a simple static deployment harder.

The distinction I had in mind is mainly useful for servers that already
have request-handling logic in front of the key material. For a static file
layout, returning the same unsuccessful result for a malformed path and a
well-formed miss seems like a reasonable tradeoff.

So I would be happy with the draft keeping this as guidance rather than an
interop requirement. Something along these lines would work for me:

A server that can distinguish a syntactically invalid HKP request path from
a well-formed request that has no matching result can return 400 Bad
Request for the former case. Clients should not rely on this distinction,
and should be prepared for static deployments or other servers to return
404 Not Found or another appropriate unsuccessful response instead.

That keeps the diagnostics and testability benefit where it is easy to
provide, without making static serving more complicated.

Best,

Songbo Bu

On Sun, 24 May 2026 09:13:00 +0000, =E2=80=9CHeiko Sch=C3=A4fer=E2=80=9D he=
[email protected]
wrote:

Hello list, Songbo,

On 5/24/26 6:11 AM, Blue Dog wrote:

On the 400 versus 404 question: the main case I had in mind is client
diagnostics and interoperability testing, not discovery of server
contents.

If the path is syntactically invalid, say a missing version component,
a non-hex character, an odd-length fingerprint, or a component with
the wrong length, a 400-class response lets a client distinguish =E2=80=9CI
built the request wrong=E2=80=9D from =E2=80=9Cthe request was well formed =
but did not
match anything.=E2=80=9D It also makes conformance tests cleaner, because
malformed-path tests can have a clear expected outcome that is
separate from normal negative lookup tests.

Such behavior would definitely be nice to have from a client
perspective. However, I think it is in some tension with the goal of
making hkpv2 easy to serve from static setups.

I don=E2=80=99t have a concrete suggestion for how this tension should be
resolved, but I wanted to raise the concern.

Thanks!
Heiko

openpgp mailing list =E2=80=93 [email protected]
To unsubscribe send an email to [email protected]

--000000000000f48d1c06528f7b7b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Heiko,</p>
<p>Yes, that is a fair concern. I do not think we should make the 400 behav=
ior a hard requirement if that would make a simple static deployment harder=
.</p>
<p>The distinction I had in mind is mainly useful for servers that already =
have request-handling logic in front of the key material. For a static file=
 layout, returning the same unsuccessful result for a malformed path and a =
well-formed miss seems like a reasonable tradeoff.</p>
<p>So I would be happy with the draft keeping this as guidance rather than =
an interop requirement. Something along these lines would work for me:</p>
<blockquote>
<p>A server that can distinguish a syntactically invalid HKP request path f=
rom a well-formed request that has no matching result can return 400 Bad Re=
quest for the former case. Clients should not rely on this distinction, and=
 should be prepared for static deployments or other servers to return 404 N=
ot Found or another appropriate unsuccessful response instead.</p>
</blockquote>
<p>That keeps the diagnostics and testability benefit where it is easy to p=
rovide, without making static serving more complicated.</p>
<p>Best,</p>
<p>Songbo Bu</p>
<p>On Sun, 24 May 2026 09:13:00 +0000, =E2=80=9CHeiko Sch=C3=A4fer=E2=80=9D=
 <a href=3D"mailto:[email protected]" target=3D"_blank">heiko.schaef=
[email protected]</a> wrote:</p>
<blockquote>
<p>Hello list, Songbo,</p>
<p>On 5/24/26 6:11 AM, Blue Dog wrote:</p>
<blockquote>
<p>On the 400 versus 404 question: the main case I had in mind is client<br=
>
diagnostics and interoperability testing, not discovery of server<br>
contents.</p>
<p>If the path is syntactically invalid, say a missing version component,<b=
r>
a non-hex character, an odd-length fingerprint, or a component with<br>
the wrong length, a 400-class response lets a client distinguish =E2=80=9CI=
<br>
built the request wrong=E2=80=9D from =E2=80=9Cthe request was well formed =
but did not<br>
match anything.=E2=80=9D It also makes conformance tests cleaner, because<b=
r>
malformed-path tests can have a clear expected outcome that is<br>
separate from normal negative lookup tests.<br>
</p>
</blockquote>
<p>Such behavior would definitely be nice to have from a client<br>
perspective. However, I think it is in some tension with the goal of<br>
making hkpv2 easy to serve from static setups.</p>
<p>I don=E2=80=99t have a concrete suggestion for how this tension should b=
e<br>
resolved, but I wanted to raise the concern.</p>
<p>Thanks!<br>
Heiko</p>


<p>openpgp mailing list =E2=80=93 <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a></p>
</blockquote>
</div>

--000000000000f48d1c06528f7b7b--


--===============4627953584640691665==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============4627953584640691665==--