<p></p>
<blockquote>
<p dir="auto">But I still don't understand what you are trying to achieve! I thought we'd clarified that we can't use any unescaped . characters from the keys in the urls, since we need . for the format separator.</p>
</blockquote>
<p dir="auto">Sorry, that might be a misunderstanding due to <a href="https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1318982892" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/3787/hovercard">issuecomment-1318982892</a>.</p>
<p dir="auto">In any case, the current code should handle the case where <code class="notranslate">%2e</code> gets decoded to <code class="notranslate">.</code> prior to the extension being handled.</p>
<blockquote>
<p dir="auto">If you are trying to support both (optional) format extensions and also dotted-keys in the url, then I believe that's a dead-end. You can't distinguish these two different situations:</p>
</blockquote>
<p dir="auto">I agree. The problem is that it is a <a href="https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1316963890" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/3787/hovercard">"hard" requirement</a> to have the ability to support <code class="notranslate">.fmt</code> on all endpoints. Which pretty much means I should make certain that <code class="notranslate">.fmt</code> works <em>now</em>. It is kind of why I <a href="https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310281511" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/3787/hovercard">initially</a> didn't want to support <code class="notranslate">.fmt</code> at all.</p>
<p dir="auto">Using <code class="notranslate">Accept</code> request headers is fine. Which leads to the question, why didn't we just use the <code class="notranslate">Accept</code> headers in the first place?</p>
<blockquote>
<p dir="auto">I don't want to see a special-case for the User Preferences API along the lines of "please note that if you have a . in your key and also the characters after the final dot happen to match one of the formats that we support (currently xml and json) then your key cannot be accessed through the direct users preferences API" or something like this. Reading between the lines, I think that's what you might be trying to achieve, but it's not clear to me.</p>
</blockquote>
<p dir="auto">I did not want to do any special casing at all. My original intent was to support arbitrary keys for the endpoint. Unfortunately, if we do support <code class="notranslate">.fmt</code>, we will of necessity need to deal with the edge case of adding another format (<code class="notranslate">.pbf</code>) or forcing clients to URL encode <code class="notranslate">.</code> themselves.</p>
<p dir="auto">Current options:</p>
<ul dir="auto">
<li>Require that clients URL encode <code class="notranslate">.</code> to <code class="notranslate">%2e</code> and hope some future update of rails doesn't bork it by url decoding prior to doing the routing
<ul dir="auto">
<li>I don't like this since it isn't exactly documented behavior. It works right now.</li>
</ul>
</li>
<li>Don't support <code class="notranslate">.fmt</code> on this endpoint and instead require clients use <code class="notranslate">Accept</code></li>
<li>Don't support <code class="notranslate">.fmt</code> on this endpoint and instead allow clients to specify an <code class="notranslate">Accept</code> header for error codes
<ul dir="auto">
<li>Clients can check the return type and go from there (<code class="notranslate">if [ media_type == "text/plain" ]; do ok_stuff; else handle_error; fi</code>)</li>
</ul>
</li>
<li>Special case <code class="notranslate">.json</code>/<code class="notranslate">.xml</code> so that <code class="notranslate">.fmt</code> works and allow <code class="notranslate">Accept</code> headers
<ul dir="auto">
<li>This is where we have to start worrying about <code class="notranslate">key</code>, <code class="notranslate">key.json</code>, and <code class="notranslate">key.xml</code> and <em>future</em> formats. Example: <code class="notranslate">key.txt</code>. Unfortunately, we cannot use a regex like <code class="notranslate">(.+?)(?=(\..*|)$)</code> This would get <em>all</em> extensions, but would also get stuff like <code class="notranslate">key.not_an_ext</code>. We could try limiting the length of the extension <code class="notranslate">(.+?)(?=(\..{,4}|)$)</code>, but we still have potential edge cases.</li>
</ul>
</li>
</ul>
<blockquote>
<p dir="auto">I don't want you to spend more of your time and effort working on debugging something that turns out to be a dead end or not useful, so I recommend that we clarify what you are trying to do before you jump in with more coding.</p>
</blockquote>
<p dir="auto">Thank you for the consideration. I've been busy the past week or so fixing JOSM tickets prior to (what I had hoped to be) a release week.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1331330015">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLMLKMA62Q5Y2RCP2UDWKZYALANCNFSM6AAAAAARZPOMC4">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLPSH4YH26WKJTUEJZDWKZYALA5CNFSM6AAAAAARZPOMC6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPLJ556.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/pull/3787/c1331330015</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1331330015",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1331330015",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>