[URL parsing]

[0xDEADBEEF]

gomaster schreef op 18 februari 2004 @ 16:26:
http://www.sarc.com/avcenter/venc/data/[e-mail]

Zoals hierboven zichtbaar is, wordt een URL met een "@" erin behandeld als een mailadres.

Is het _{vast wel} mogelijk om, als er "http://" aan het begin staat het dan ook als hyperlink verder te verwerken ?

[disjfa]

[url] ervoor zetten en [/] erachter

[0xDEADBEEF]

Met [url] : http://[e-mail]

Met [url]: http://www.sarc.com/avcenter/venc/data/[e-mail]

Zonder [url] : http://www.sarc.com/avcenter/venc/data/[e-mail]

/voorbeeld

disjfa schreef op 18 februari 2004 @ 16:34:
[url] ervoor zetten en [/] erachter

Ja OK, maar waar ik op doel: het resultaat van een link niet tussen tags met http:// en zonder @ erin zou toch hetzelfde moeten zijn als wel tussen tags en met http:// ervoor en een @ erin

[Verwijderd]

http://www.sarc.com/avcen...ta/w32.netsky.b%40mm.html

@ in een url (op die plek en met die betekenis) is gewoon een slechte gewoonte.

[Spider.007]

quote: http://www.faqs.org/rfcs/rfc1738.html

[...]
Unsafe:

Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs.The characters "<" and ">" are unsafe because they are used as thedelimiters around URLs in free text; the quote mark (""") is used todelimit URLs in some systems. The character "#" is unsafe and shouldalways be encoded because it is used in World Wide Web and in othersystems to delimit a URL from a fragment/anchor identifier that mightfollow it. The character "%" is unsafe because it is used forencodings of other characters. Other characters are unsafe becausegateways and other transport agents are known to sometimes modifysuch characters. These characters are "{", "}", "|", "\", "^", "~","[", "]", and "`".

All unsafe characters must always be encoded within a URL. Forexample, the character "#" must be encoded within URLs even insystems that do not normally deal with fragment or anchoridentifiers, so that if the URL is copied into another system thatdoes use them, it will not be necessary to change the URL encoding.

Reserved:

Many URL schemes reserve certain characters for a special meaning:their appearance in the scheme-specific part of the URL has adesignated semantics. If the character corresponding to an octet isreserved in a scheme, the octet must be encoded. The characters ";","/", "?", ":", "@", "=" and "&" are the characters which may bereserved for special meaning within a scheme. No other characters maybe reserved within a scheme.

Usually a URL has the same interpretation when an octet isrepresented by a character and when it encoded. However, this is nottrue for reserved characters: encoding a character reserved for aparticular scheme may change the semantics of a URL.

Thus, only alphanumerics, the special characters "$-_.+!*'(),", andreserved characters used for their reserved purposes may be usedunencoded within a URL.

On the other hand, characters that are not required to be encoded(including alphanumerics) may be encoded within the scheme-specificpart of a URL, as long as they are not being used for a reservedpurpose.

Dus: een '@' symbol valt onder de reserved characters en de manier van intepreteren op GoT is correct en volgens de standaarden. Door het gebruiken van [url] tags kun je dit gedrag alsnog omzeilen

[Osiris]

Verwijderd schreef op 18 februari 2004 @ 16:47:
http://www.sarc.com/avcen...ta/w32.netsky.b%40mm.html

@ in een url (op die plek en met die betekenis) is gewoon een slechte gewoonte.

Oftewel, React zou eigenlijk een urlencode() moeten gebruiken bij het parsen van url's en/of zou de gebruiker dit moeten doen?

Kan me voorstellen dat een auto-url-encode een nuttige functie is

[0xDEADBEEF]

Het was BTW niet mijn post, doe het zelf altijd op de "goede manier"

[Spider.007]

Osiris schreef op 18 februari 2004 @ 16:50:
[...]

Oftewel, React zou eigenlijk een urlencode() moeten gebruiken bij het parsen van url's en/of zou de gebruiker dit moeten doen?

Kan me voorstellen dat een auto-url-encode een nuttige functie is

En hoe moet dan bepaald worden of een character wel of niet een onderdeel is van de URL? Het '@' symbool valt immers al onder characters die niet gebruikt mogen worden in de URL; netzoals de spatie (wat jij waarschijnlijk als mooi scheidingsteken zou zien )

[0xDEADBEEF]

Verwijderd schreef op 18 februari 2004 @ 16:47:
http://www.sarc.com/avcen...ta/w32.netsky.b%40mm.html

@ in een url (op die plek en met die betekenis) is gewoon een slechte gewoonte.

Hoezo het is IMHO slecht dat een URL beginnend met http:// mogelijk geparsed wordt als een mailadres.

[BtM909]

LaLaLand schreef op 18 februari 2004 @ 16:59:
[...]


Hoezo het is IMHO slecht dat een URL beginnend met http:// mogelijk geparsed wordt als een mailadres.

Tuurlijk niet. Het is eigenlijk geen goede URI.

Het volgende wordt ook niet geparsed:

http://doeidoeidoeidoei

[crisp]

een @ in een url is heel normaal:

http://usernaam:[e-mail]

echter heeft Microsoft onlangs besloten deze support er in IE uit te slopen

een @ in de domein naam is echter bad habbit

[ Voor 14% gewijzigd door crisp op 18-02-2004 17:04 ]

[moto-moi]

BtM909 schreef op 18 februari 2004 @ 17:00:
Tuurlijk niet. Het is eigenlijk geen goede URI.
Het volgende wordt ook niet geparsed:
http://doeidoeidoeidoei

Oh ?
http://ru

Is toch echt een geldig URL hoor
OK, je komt het niet vaak tegen dat een tld een www server staat, maar in rusland letten ze daar niet zo op geloof ik

Maargoed, dit gaat dus over de software, dus ik tik deze even naar React Bugs en Featurerequests, ik gok dat er wel een goede reden voor is dat het niet werkt, omdat je met een @ een username aan kunt geven e.d., en IE zal daar wel rare dingen mee doen

[decramy]

en http://localhost/index.php ? das volgens mij wel de bekendste....

[ Voor 9% gewijzigd door decramy op 18-02-2004 17:11 ]

[Verwijderd]

decramy schreef op 18 februari 2004 @ 17:11:

en http://localhost/index.php ? das volgens mij wel de bekendste....

Ik vind het niet zo erg dat dat niet werkt. Ik vind het zelfs een prettige bijkomstigheid. Net als de @ op een verkeerde plaats in een url niet herkend wordt als deel van de url. Wat mij betreft laten we het lekker zo.

[BtM909]

moto-moi schreef op 18 februari 2004 @ 17:05:
[...]

Oh ?
http://ru

't zal best, maar mien browser kan die pagina niet weergeven
_{alszijnde: pagina niet gevonden}

[Osiris]

Spider.007 schreef op 18 februari 2004 @ 16:58:
[...]


En hoe moet dan bepaald worden of een character wel of niet een onderdeel is van de URL? Het '@' symbool valt immers al onder characters die niet gebruikt mogen worden in de URL; netzoals de spatie (wat jij waarschijnlijk als mooi scheidingsteken zou zien )

@ zal dus veranderen naar een %** waarde door de functie urlencode

Overigens neem ik aan dat de functie urlencode een @ niet veranderd naar %.. als hij gebruikt wordt als scheiding tussen username/pass en hostname Niet getest, maar zo slim is PHP ook wel weer gok ik..

[Verwijderd]

Osiris schreef op 18 februari 2004 @ 17:48:

@ zal dus veranderen naar een %** waarde door de functie urlencode

Overigens neem ik aan dat de functie urlencode een @ niet veranderd naar %.. als hij gebruikt wordt als scheiding tussen username/pass en hostname Niet getest, maar zo slim is PHP ook wel weer gok ik..

urlencode hoort nou _juist_die_ tekens te encoden.

[chem]

Verwijderd schreef op 18 februari 2004 @ 17:14:
[...]

Ik vind het niet zo erg dat dat niet werkt. Ik vind het zelfs een prettige bijkomstigheid. Net als de @ op een verkeerde plaats in een url niet herkend wordt als deel van de url. Wat mij betreft laten we het lekker zo.