--follow assumes that Location is relative

[nebhale]

Currently the --follow flag's behavior assumes that the Location returned is relative (if it is not qualified with http://). In other words, a POST to http://localhost:8080/foo that returns Location: /foo/1 will result in the shell pointing at http://localhost:8080/foo/foo/1.

The --follow implementation should inspect whether the value of Location is relative or absolute and update the URI appropriately in both cases.

Note that by spec, this value should never be interpreted as a relative URL. However, Wikipedia seems to indicate that most browsers do so.

[jbrisbin]

There is no inspection of the URL done at all. The value returned in the Location header should, by the spec, be an absolute URI. So whatever is in Location gets passed to setting the baseUri as-is:

if(follow && response.getHeaders().containsKey(LOCATION_HEADER)) {
  try {
    configCmds.setBaseUri(response.getHeaders().getFirst(LOCATION_HEADER));
  } catch(URISyntaxException e) {
    LOG.error("Error following Location header: " + e.getMessage(), e);
  }
}

Location: /foo/1 is invalid (it's not a URI, it's a path) and should not be returned. Thus Location: foo/1 is even more invalid.

The real issue is what to do in cases that violate the spec. If the Location starts with a '/', then take the baseUri and replace the path portion of the URI, but if there is no leading '/', use the baseUri + the given path seems logical. But that's just making it a lot easier to develop services that clearly violate the spec. But I guess if the point is to make things easy that people are going to do anyway, why not just drop the pretense and make it easy?

[jbrisbin]

/cc @olivergierke @markpollack