[bug] Filter naam

[EWK]

Als ik een topic neem waarin ik gereageerd heb, en dan in bij zoeken mijn nickname in vul (om even mijzelf als voorbeeld te nemen), en dan uit de dropdown zoeken --> Dit topic : Poster klik, dan krijg uiteraard netjes een overzicht van al mijn reacties in dat topic.

Als ik die url kopieer uit de adresbalk en vervolgens wil posten, dan krijg ik :

code:

http://gathering.tweakers.net/forum/list_messages/1098284?data[filter_userids]=ewk

Hier wordt automagisch van gemaakt:
Het grote Toyota-topic[filter_userids]=ewk

En pakt hij hem niet goed op, ik kom immers terecht in het Toyota Topic, en niet bij de reacties van mij in het Toyota topic, hij laat de [filter_userids]=ewk dus denk ik links liggen, zoals je in de gegeneerde url dus ook ziet.

[pven]

Probeert het eens met dubbele quotes.

Ah, je hebt het over automatisch. Dit kost je iets meer werk, maar werkt wel.

[ Voor 49% gewijzigd door pven op 21-02-2010 18:44 ]

[Osiris]

quote: http://www.apps.ietf.org/rfc/rfc2396.html#sec-2.4.3

2.4.3. Excluded US-ASCII Characters

Although they are disallowed within the URI syntax, we include here a description of those US-ASCII characters that have been excluded and the reasons for their exclusion.

The control characters in the US-ASCII coded character set are not used within a URI, both because they are non-printable and because they are likely to be misinterpreted by some control mechanisms.

control = <US-ASCII coded characters 00-1F and 7F hexadecimal>

The space character is excluded because significant spaces may disappear and insignificant spaces may be introduced when URI are transcribed or typeset or subjected to the treatment of word- processing programs. Whitespace is also used to delimit URI in many contexts.

space = <US-ASCII coded character 20 hexadecimal>

The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields. The character "#" is excluded because it is used to delimit a URI from a fragment identifier in URI references (Section 4). The percent character "%" is excluded because it is used for the encoding of escaped characters.

delims = "<" | ">" | "#" | "%" | <">

Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters.

unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

Data corresponding to excluded characters must be escaped in order to be properly represented within a URI.

Die zul je dus eerst moeten escapen, voordat ze toegestaan zijn in een URL en derhalve is het IMO ook wel logisch dat de GoT parser hem niet opneemt bij het automatisch vormen van een link.

edit:

Hm, Firefox doet normaliter forbidden characters wel escapen als je het uit de adresbalk C/P't, maar deze keer ook niet..

[ Voor 3% gewijzigd door Osiris op 21-02-2010 18:52 ]

[EWK]

Dus je zegt dat het simpelweg niet mogelijk is, maar is het dan niet handig om dan maar iets dat niet klikbaar is, maar wel de juiste link genereert te creëren, in plaats van iets dat niet werkt?
Iets zoals dus:

code:

http://gathering.tweakers.net/forum/list_messages/1098284?data[filter_userids]=ewk

[Osiris]

EWK schreef op zondag 21 februari 2010 @ 18:52:
Dus je zegt dat het simpelweg niet mogelijk is, maar is het dan niet handig om dan maar iets dat niet klikbaar is, maar wel de juiste link genereert te creëren, in plaats van iets dat niet werkt?
Iets zoals dus:

code:

http://gathering.tweakers.net/forum/list_messages/1098284?data[filter_userids]=ewk

Nee, ik zeg dat 't prima werkt zodra je die [ en ] escapet naar de correcte escaped characters

Check:

code:

http://gathering.tweakers.net/forum/list_messages/1396106?data[filter_userids]=osiris

Werkt niet: [bug] Filter naam[filter_userids]=osiris

code:

http://gathering.tweakers.net/forum/list_messages/1396106?data%5Bfilter_userids%5D=osiris

Werkt wel: [bug] Filter naam

Dit omdat de 1e methode gewoon géén geldige URL is (in z'n totaliteit) en derhalve 'hoeft' die ook niet als dusdanig geparst te worden lijkt me, strikt gezien.

[ Voor 35% gewijzigd door Osiris op 21-02-2010 18:56 ]

[Wiethoofd]

Zie ook: [bug] URL gaat mis met Array in GET-parameters en [bug]Forum: Lange URL niet geparsed

[ Voor 28% gewijzigd door Wiethoofd op 21-02-2010 18:57 ]

[EWK]

Okee, maar waarom moet ik die skippen? Er kan dan toch ook een link worden gegenereerd die het wel goed op pakt?

Edit: Aah, die had ik nog niet gezien

[ Voor 16% gewijzigd door EWK op 21-02-2010 18:57 ]

[moto-moi]

Tsja, firefox bug dus, helaas.

[crisp]

Ik zou dit wel op kunnen lossen, maar uiteindelijk is het inderdaad een bug in Firefox

[moto-moi]

Ja, maar jij bent dan ook RG