On Mon, Sep 16, 2013 at 6:34 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: When talking about URI design and REST, it has nothing to do with functionality, but with organization and logical design. In URIs, the path part of the URI is considered a hierarchical structure. It doesn't make sense for api.php to be a sub-resource of the wiki itself. Even doing some sort of underscore design wouldn't make sense, because you're implying that the _images/ resource is the same level sub-resource as a normal article. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On 09/16/2013 04:09 PM, Petr Onderka wrote: Ah, ok. That would make it hard to keep /w/api.php working. /_w/api.php would not suffer from that problem, but then current API users would break. So I guess that kills the /wiki/ removal in the shorter term. Maybe we should however consider using something like /_w/ if we ever introduce a new API entry point to avoid conflicts with valid article names in the future. Gabriel

On Tue, Sep 17, 2013 at 8:34 AM, Gabriel Wicke &lt;gwicke(a)wikimedia.org&gt; wrote: I bet people have said that about single letter interwikis, but we do have quiet a few "<single letter>:" page titles around. have "<single letter>/" is not un-believable.

On 2013-09-17 2:29 AM, Nikola Smolenski wrote: The problem with that query is you're searching Wikipedia. Try Wiktionary instead. I found 5 just on the first letter I tested https://en.wiktionary.org/wiki/Special:PrefixIndex/a/ Also pages prefixed with "<single letter>/" aren't the only thing that creates conflicts. As far as standard rewrite rules and webservers are considered a directory at /a/ and /a are the same thing. See how https://en.wikipedia.org/w is not a 404 pointing to [[w]] like https://en.wikipedia.org/a is but instead is the same as w/ and hence w/index.php. So really any single letter article on a root pathed wiki conflicts with any single letter root directory. ;) And Wikipedia has a redirect like that for every single letter of the latin alphabet. (Actually forget the latin alphabet, they've practically got most of Unicode there) Side topic https://en.wiktionary.org/w/r/t is messed up: " To check for "r/t" on Wikipedia, see: //en.wikipedia.org/wiki/r/t <https://en.wikipedia.org/wiki/r/t>" ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 09/17/2013 05:59 AM, Daniel Friesen wrote: Good catch, filed: https://bugzilla.wikimedia.org/show_bug.cgi?id=54357 Matt Flaschen

On 2013-09-17 2:48 AM, Daniel Kinzler wrote: +1 We've got others for content-related things too besides ones for internal resources and structured data. eg: https://test2.wikipedia.org/s/85 ((And I'll try to resist starting a rant about the knockoff "REST" which is a partial premise here)) ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Tue, 17 Sep 2013, at 7:51, Tyler Romeo wrote: I would be concerned about proper work of this feature in wikilinks. [[Main Page?action=history|Foo]] makes a red broken link.

On Mon, Sep 16, 2013 at 4:41 PM, Gabriel Wicke &lt;gwicke(a)wikimedia.org&gt; wrote: Any of the entry points? Any new entry point? Anything we ever want to put into the root? - Ryan

On 2013-09-16 7:09 PM, Gabriel Wicke wrote: Has the practice of disallowing /w/ or /index.php inside robots.txt to force search engines to completely ignore search, edit pages, exponential pagination, etc.. been considered? Btw, side note on root urls. We still have an open bug allowing attacks on wikis using root paths: https://bugzilla.wikimedia.org/show_bug.cgi?id=38048 ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

I would suggest taking a look at the number of 404s caused by people trying to access pages without the wiki prefix.... This would be interesting data to go alongside this interesting proposal... On 16 Sep 2013 20:01, "Gabriel Wicke" &lt;gwicke(a)wikimedia.org&gt; wrote:

Note also that zhwiki (and others?) profitably uses the first part of the path to do variant selection. https://zh.wikipedia.org/wiki/User:Cscott uses the wiki default variant (if logged in, uses the variant from the user's preferences) https://zh.wikipedia.org/zh-hans/User:Cscott https://zh.wikipedia.org/zh-hk/User:Cscott etc use the specified variant. I have a dream to eventually enable https://en.wikipedia.org/en-gb/Football in a similar fashion. --scott

On 20/09/13 03:04, Jon Robson wrote: I think the request rate for actual articles in the root is very, very low. And if you look at the paste I gave earlier: http://paste.tstarling.com/p/uhtFqg.html there's reason to think that the amount of traffic that comes from naive readers typing URLs and expecting an article is much smaller than even 149k per week. A naive user would be more likely to type a URL starting with a lower-case letter, and if you take those entries, and filter out the obvious client bugs and typos, that leaves only 39 log entries. If we filter out some more log entries that are unlikely search terms for Wikipedia articles ("enregistrement-audio-musique", "is", "unlimited_data_plan", etc.), that leaves maybe 30. http://paste.tstarling.com/p/KWuHif.html Of these, only 12 actually correspond to Wikipedia articles or redirects: abolition addicting_games apple_inc carnaval dreamshade facade girls insidious karthik online_coupons snam walkabout So the number of naive readers actually helped by our 404 Refresh to /wiki/ is probably closer to 12k per week than 149k per week. Personally, I think the refresh is annoying, since it makes it much more difficult to correct typos in manually-typed URLs. If you actually meant to type some non-article URL like a CSS resource, and make a typo which causes it to hit the refresh, the URL you typed is erased from your browser's address bar and history, making correction of the typo much more difficult. Maybe we should just include a link to the search page, rather than redirect or refresh. -- Tim Starling

On 19 Sep 2013 18:23, "Tim Starling" &lt;tstarling(a)wikimedia.org&gt; wrote: I agree.. Sorry I guess my message wasn't so clear. I meant "existing" URL structure :) And if you look at the paste I gave earlier:

On 2013-09-16 8:01 PM, Gabriel Wicke wrote: Ok. Though even assuming the * and Allow: non-standard features are supported by all bots we want to target I actually don't like the idea of blacklisting /wiki/*? in this way. I don't think that every url with a query in it qualifies as something we want to blacklist from search engines. There are plenty but sometimes there is content that's served with a query which could otherwise be a good idea to index. For example the non-first pages on long categories and Special:Allpages' pagination. The latter has robots=noindex – though I think we may want to reconsider that – but the former is not noindexed and with the introduction of rel="next", etc... would be pretty reasonable to index but is currently blacklisted by robots.txt. Additionally while we normally want to noindex edit pages. This isn't true of redlinks in every case. Take redlinked category links for example. These link to an action=edit&redlink=1 which for a search engine would then redirect back to the pretty url for the category. But because of robots.txt this link is masked because the intermediate redirect cannot be read by the search engine. The idea I had to fix that naturally was to make MediaWiki aware of this and whether by a new routing system or simply filters for specific simple queries make it output /wiki/title?query urls for those cases where it's a query we would want indexed and leave robots blacklisted stuff under /w/ (though I did also consider a separate short url path like /w/page/$1 to make internal/robots blacklisted urls pretty). However adding Disallow: /wiki/*? to robots.txt will preclude the ability to do that. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 09/16/2013 08:48 PM, Jeremy Baron wrote: Yes, sorry. The RFC had it right, in case you read that ;) Gabriel

On 09/17/2013 08:40 AM, Brad Jorsch (Anomie) wrote: An end point that wants to be cacheable should only use one query parameter, which might well be a path. Hypothetical examples: http://wiki.org/wiki/Foo?r=latest/html http://wiki.org/wiki/Foo?r=123456/wikitext An alternative solution would be to specify a list of required query parameters and a canonical ordering, and to reject (or redirect) requests not conforming to this spec. The problem I see with this approach is that many client libraries don't provide control over the order of query parameters, which would make such an interface hard to use. Gabriel

On 09/17/2013 11:24 AM, Brad Jorsch (Anomie) wrote: I consider the article to be the main resource we are interested in, with a revision and then a specific part (format) of that revision as a sub-resource. As our titles can contain slashes we need to delimit the main resource from the sub-resource part. A single query parameter that specifies the sub-resource path achieves that. A heavily-used content API will perform better and use less resources when it is cacheable. This will become more important over time, so I believe it is worth spending a small amount of effort on now. Gabriel

----- Original Message ----- Concur, especially in light of the face that *this does not permit you to break the old URLs*. They are everywhere, *and they must continue to work forever*. I hope I don't even have to justify why. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On Mon, Sep 16, 2013 at 8:20 PM, Steven Walling &lt;steven.walling(a)gmail.com&gt;wrote;wrote: To be fair, both of those links redirect to the proper URL anyway. It wouldn't be hard to just change that from 404 to a redirect. Nonetheless the canonical URI should still be /wiki/Article_title. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On 17/09/13 11:08, Gabriel Wicke wrote: This issue affects IE at least up to IE 6, possibly later, see bug 28235. -- Tim Starling

On 17/09/13 14:01, Gabriel Wicke wrote: I'm assuming you can grep for Content-Disposition as well as I can. IIRC, the difficulty with Content-Disposition, in the context of a security patch, was the need to abstract handling of the header out of the various places that send it, so that it would be consistent and demonstrably secure. That would have made the security patch larger and more complex than it needed to be, which would have been a problem for backporters. That shouldn't be a concern for your feature. -- Tim Starling