https://bugzilla.wikimedia.org/show_bug.cgi?id=30712
--- Comment #1 from Neil Kandalgaonkar <[email protected]> 2011-09-08 00:44:05 UTC --- (In reply to comment #0) I would like to understand this issue a bit more. Where exactly would problems arise? > * Change the loose/strict parse regex to accept procol-relative urls Makes sense to me > * Add a static method: mw.Uri.expandUrl (which adds protocol (if not present) > and perhaps wgServer as well if needed) That makes the current URL an implicit argument. That seems wrong and could be confusing. When do you use .expandUrl() and when do you just use .toString() ? There is no confusion in the model of the URL, which does always have a protocol and an authority (server) section. What I think you want, maybe, is some different way of outputting that URL, that suppresses the protocol and authority section. But since this runs in the browser only, we always know the protocol and authority anyway. So why would we ever want a protocol-relative URL at that point? So would this be okay? # within https://sample.com/ var url = new mw.Uri( 'http://sample.com/foo/bar' ); console.log( url ) // prints "http://sample.com/foo/bar"; var PRurl = new mw.Uri( '//foo/bar' ); console.log( PRurl ) // prints "https://sample.com/foo/bar"; > * Add prototype function that returns true/false depending on whether the > protocol is in wgUrlProtocols Why not do it like this? $.inArray( wgUrlProtocols, url.protocol ) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
