In addition to a self written gopher server I also have a QOTD server accepting requests via TCP and UDP. I never mentioned it as I just put it out there to really see what would happen. I will occasionally see a request go by, but over the past two weeks, some people have really been hitting it hard via UDP:
There doesn't see to be much I can find about this,
other than a potential link to XBox Live,
but that doesn't
It's hard to say.
So to see what might be happening,
I modified the QOTD program to record anything it receives via UDP.
I should be able to figure out if
188.8.131.52 is trying to attack something,
or if it really just wants an up-to-date quotes file.
Any field which is defined in a document published as a formal extension to this specification; none will have names beginning with the string "X-" …
This also applies to headers starting with “x-” as Internet based text headers are case-insensitive.
Fields may appear in messages that are otherwise unspecified in this document. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text that conforms to the unstructured syntax.
The field names of any optional field MUST NOT be identical to any field name specified elsewhere in this document.
Hmm … nothing about “X-”. I replied that starting a non-standard header with “X-” was still a safe way to go, only for Cunningham's Law to kick into effect:
- Daurnimator <XXXXXXXXXXXXXXXXXXXX>
- Lua mailing list <email@example.com>
- Re: Adding another way to point to "levels" to debug.getinfo and friends
- Mon, 13 May 2019 11:55:07 +1000
On Mon, 13 May 2019 at 09:03, Sean Conner <firstname.lastname@example.org> wrote:
In other RFC documents (too many to mention) private or experimental fields are usually labeled with "X-" (or "x-") so your best bet is to create a header name starting with "X-" to be safe.
Please stop using the X- prefix! See RFC 6648:
This document generalizes from the experience of the email and SIP communities by doing the following:
1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].
Interesting. The “X-” standard for non-standard headers was to allow for experimentation without fear of conflicting with other headers, but the process of converting such headers to a standard header prove problematic. But RFC-6648 does cover the case when one doesn't want to standardize a header (or parameter):
… In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122].
What a wild idea!