On 3/28/21 9:44 AM, Jonathan S. Katz wrote:
>
>
>> On Mar 28, 2021, at 7:26 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>
>> On Sat, Mar 27, 2021 at 8:35 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>>
>>>> On 3/25/21 8:20 AM, Magnus Hagander wrote:
>>>> On Wed, Mar 24, 2021 at 8:57 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>>>>
>>>>> I've modified the URL matching to be all uppercase, but keeping our
>>>>> matching logic case insensitive.
>>>>
>>>> I do still prefer lowercase, but not enough to insist on it :)
>>>>
>>>> But do consider the redirect, that might help some ppl.
>>>
>>> OK, so I did:
>>>
>>> - matching cve/CVE
>>> - added a redirect to rewrite to CVE
>>
>> Wouldn't:
>> + if request.path.find('cve') != -1:
>> + return redirect('/support/security/CVE-{}/'.format(cve),
>> permanent=True)
>>
>> you captured the "cve" vs "CVE" part already in urls.py as a separate
>> parameter? And then just "if blah != 'CVE' return redirect"?
>>
>> Either works, but looking for cve anywhere in the URL seems to set up
>> for a future bug should we ever for example want to move the cve's
>> into a subdir..
>
> We don’t capture the “cve” string in a variable and I think it’s a bit overkill
> to do so. We only capture the numbers.
>
> And if we made that move to a subdir, we’d have to update the URL
> pattern anyway, so this seems to be a bit of prefactoring.
>
> So I’m disinclined to change it.
Looking at it more closely, I do see how it's "one step away" from
capturing the string value. I do think it's a bit overkill given the
vast majority of traffic will be to the uppercase, but I'm now a bit
more open-minded to applying your suggestion and calling it complete.
Jonathan