[fp] Tags met slashes werken niet

[Sando]

Volgens mij werken tags met slashes niet helemaal lekker, zoals de tag /e/OS onderaan dit artikel:

nieuws: Maker van Android-alternatief /e/OS brengt dit jaar nieuwe Murena-tel...

Als je op de tag klikt krijg je een foutmelding.

Ik merk het op meerdere computers/browsers, dus lijkt het me niet browserspecifiek.

[DaFeliX]

Bedankt voor jouw melding, ik ben er in gedoken en heel wat geleerd over hoe routing onderhuids werkt in Symfony.

Dat was 't goede nieuws, het slechte nieuws is dat Symfony hier in de weg zit en het niet triviaal is om dit te fixen.

De URLs van tags worden op de volgende manier opgebouwd: "/tag/NAAM/nieuws", waarbij NAAM wordt vervangen door de naam van de tag.
Wanneer er een slash in de naam van de tag staat, zou je een andere URL kunnen krijgen. Daarom encoderen wij de slashes in de tag: "/tag/%2Fe%2FOS/nieuws/".
Op deze manier kunnen we in onze router matchen op "/tag/NAAM/nieuws", waarbij NAAM uit alles mag bestaan behalve een slash.
In mijn ogen doen we het dus goed, alleen vertaald de route matcher van Symfony de "%2F" door een slash, waardoor de router de URL interpreteert als "/tag//e/os/nieuws", waarop onze route niet meer matcht (onze route zegt immers dat een tag niet uit slashes mag bestaan).
IMO is dit een fout in Symfony, maar Symfony denkt daar anders over (lezende in de gemelde bugreports hierover).

We zouden de tag natuurlijk twee keer kunnen encoderen, dan werkt de route matcher in elk geval wel, maar dan moeten we in de applicatie de URL weer decoderen. Met de kans dat bestaande URLs dan weer niet matchen...

Ik heb er een bugticket voor gemaakt zodat we hier 'ns rustig naar kunnen kijken.

[Sando]

Bedankt voor de uitleg, interessant om te lezen.

Wikipedia gebruikt meen ik ook Symfony, dus ik ging daar ook even kijken. Daar werkt een route met dubbele slash wel:
en.wikipedia.org/wiki//e/_(operating_system)
Misschien is de Symfony router slimmer dan je denkt, en komt het goed als je de slashes gewoon laat staan zonder encodering?

Ik zie trouwens (bijna) nooit tags met slashes, dit is de eerste keer dat ik deze fout tegenkom. Misschien is het wel zo aantrekkelijk om in tags de slashes gewoon weg te halen, en er bijvoorbeeld "e-os" van te maken.

[ Voor 17% gewijzigd door Sando op 27-10-2023 13:30 ]

[DaFeliX]

Sando schreef op vrijdag 27 oktober 2023 @ 13:28:
Bedankt voor de uitleg, interessant om te lezen.

Wikipedia gebruikt meen ik ook Symfony, dus ik ging daar ook even kijken. Daar werkt een route met dubbele slash wel:
en.wikipedia.org/wiki//e/_(operating_system)
Misschien is de Symfony router slimmer dan je denkt, en komt het goed als je de slashes gewoon laat staan zonder encodering?

Slashes kunnen ook wel werken, als je het zo doet:

PHP:

class DefaultController extends AbstractController
{
    #[Route('/tag/{slug}', requirements: ['slug' => '.+'])]
...

.+ betekend hier in reguliere expressie: elk teken, tenminste 1 teken lang.

Alleen is er bij Tweakers niet alleen de pagina /tag/e-os/, maar ook andere pagina's zoals /tag/e-os/nieuws/.

Daarom matchen wij niet op .+, maar op [^/]+ (reguliere expressie voor elk teken zolang het maar geen slash is, tenminste 1 teken lang). Op die manier kunnen we ook subpagina's (en evt nog een nesting dieper) matchen. Dat zou werken, als Symfony niet %2F vertaald naar een slash voordat de reguliere expressie wordt uitgevoerd.

Als een tag altijd als laatste kwam hadden we ook .+ kunnen gebruiken, maar omdat de tag er tussen inzit wordt dat lastiger.

[DaFeliX]

@Sando ondertussen heeft mijn collega niet stilgezeten en het probleem opgelost. Nogmaals dank voor je melding!

[milo526]

DaFeliX schreef op maandag 6 november 2023 @ 13:20:
@Sando ondertussen heeft mijn collega niet stilgezeten en het probleem opgelost. Nogmaals dank voor je melding!

Puur uit nieuwsgierigheid; hoe is dit nu uiteindelijk opgelost?

[DaFeliX]

milo526 schreef op maandag 6 november 2023 @ 13:25:
[...]


Puur uit nieuwsgierigheid; hoe is dit nu uiteindelijk opgelost?

Door toch [.*] te gebruiken.

We hebben dit getest en gezien dat de Router prima in staat is om alle routes op die manier goed af te handelen. Het lijkt er op dat de Router de minder-specifieke regel later uitvoert, waardoor 't voor bijna alle gevallen nu werkt.
Dat wil zeggen, wanneer er een categorie "iets/nieuws" bij zou komen krijgen we wellicht wel problemen omdat ie dan wss niet 't verschil kan zien tussen de categoriepagina voor "iets/nieuws" ("/tags/iets%2Fnieuws") en de nieuwspagina van de categorie "iets" ("/tags/iets/nieuws").

[Sando]

Dan is die Symfony router dus toch iets slimmer dan waar het credits voor kreeg.

Netjes opgelost. Bedankt voor de terugkoppeling!