I think for clients is good to obtain always a response, and flag it as redirected or not redirected in JSON.

I think a most common API is action=query to fetch the article.
In this case I would like to have the redirected handled by default, and return a JSON like (pseudo-code here, not json syntax):
[query][pages]:{ [7955] : {[page] : {DNA html is here}, [redirect] : false }
[query][pages]:{ [7956] : {[page] : {DNA html is here}, [redirect] : true }
if not redirect is specified:
[query][pages]:{ [7956] : {[page] : {Dna is redirect}, [redirect] : false } }, [redirects] : { [7956] : { Final redirected Page goes here, or alternatively a whole list of redirect pointing to final redirect } }

@Gg4u, I don't think we want to wrap all HTML responses in JSON. This would be a drastic change, and would introduce some non-trivial overheads. The proposal is to use regular HTTP semantics by sending a HTTP redirect, along with the regular response body. This means that the full HTML of redirects *is* included.

Clients can decide whether to follow the redirect automatically or not, by setting the corresponding flag in curl / fetch / urllib / $HTTP_LIB. Many will want to, but others like VisualEditor will disable automatic following to edit the redirect itself.

Some implementation notes based on a conversation @Pchelolo & I had in the office earlier today:

• The MediaWiki API already returns a boolean 'redirect' flag indicating that the *latest* revision of this title is a redirect (it's only stored in the page table). We already store this, so can use it to find redirects in *current* revisions.
  • We can't really trust this for old revisions, so might need to check the content for now.
• We need to add a per-revision redirect boolean in the upcoming restrictions table.
• We discussed whether we should redirect requests asking for a specific revision as well. On balance, it seems more consistent to do so (and support ?redirect=no).

@BBlack, what is your take on the Varnish part of option 3? Our goal is to share cache entries between redirected responses (302, location header, body) & no-redirect variants (200, no location header, body). Concretely, we would do something like the following for requests to /api/rest_v1/:

• Match and strip ?redirect=no in the URL; set a no_redirect flag on the request.
• In the response (cached or not) path, if status 302 and no_redirect flag is set:
  • Replace status with 200
  • Strip Location header

Does this sound sane to you?

I hate it, but I don't see any better way to solve the problem at present.

To reword to be sure I have the intent:

1. On the vcl_recv side, for /api/rest_v1 requests, strip and note (via req.http.Foo as an internal request flag) the ?redirect=no argument. We'll need to support that in all its forms without screwing up other arguments - we've done that before elsewhere in VCL. I think the best example is in templates/varnish/analytics.inc.vcl.erb, in function analytics_provenance_recv_ where we strip the wprov argument from any position in the argument list by using a pair of regexen.

2. On the vcl_deliver side, if the flag from above is set && status == 302, we'll overwrite the status as "200 OK" and delete the Location header.

@BBlack: Yes, that captures the idea very well.

I'm also not too fond of the VCL part of this, but couldn't come up with anything better.

We'll initially deploy this without caching for the ?redirect=no requests, so there is no rush to implement the VCL bits. We'll probably look into that later this quarter.

In T118548#2201380, @GWicke wrote:

We'll initially deploy this without caching for the ?redirect=no requests, so there is no rush to implement the VCL bits. We'll probably look into that later this quarter.

The mailing list post mentioned ?redirect=false. Will any falsey value work with this parameter?

I have some vague memory that the value of some URL parameters, when passed to MediaWiki's api.php, will change the response behavior regardless of the parameter's value. The URL parameter being present in the request URL is all that's needed, as I recall. I'm wondering if matching that behavior here would be great or terrible.

In T118548#2209015, @MZMcBride wrote:

The mailing list post mentioned ?redirect=false. Will any falsey value work with this parameter?

We've added redirect=no support to RESTBase to match MW syntax about redirects, but basically it's a false.

In RESTBase false is a string false, FALSE, 1 and now no. However, we don't want to advertise all of these options, as for caching it's better to have just one, so we will probably stick with false in all the documentation/mailing lists/etc.

In MW api the parameters which just need to be present have a semantics of true with a false default, however here we have the opposite, so it's better to be explicit here.

In T118548#2209015, @MZMcBride wrote:

I have some vague memory that the value of some URL parameters, when passed to MediaWiki's api.php, will change the response behavior regardless of the parameter's value. The URL parameter being present in the request URL is all that's needed, as I recall. I'm wondering if matching that behavior here would be great or terrible.

Right... from https://en.wikipedia.org/w/api.php#main.2Fdatatypes:

Boolean parameters work like HTML checkboxes: if the parameter is specified, regardless of value, it is considered true. For a false value, omit the parameter entirely.

What happens with ?redirect=yes or other truthy values?

What happens with ?redirect=yes or other truthy values?

It's considered to be true and the redirect happens. However here redirect is the default behaviour, so there's no point to be explicit.

I guess the question remains, though: if the Varnish redirect-stripper sees ?redirect with a non-falsey value, should it still strip the parameter?

In T118548#2209336, @BBlack wrote:

I guess the question remains, though: if the Varnish redirect-stripper sees ?redirect with a non-falsey value, should it still strip the parameter?

Yes. We care only about the false-y case.