POST returns 302 Redirect to be GETted

I have a POST call triggering a 302 redirect

HTTP/1.1 302 Found
Server: csw
Cache-Control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Date: Mon, 31 Oct 2016 16:57:40 GMT
Location: //
Expires: -1
Pragma: no-cache
Content-Length: 119

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="//">here</a>.</h2>

which is apparently to be GETted as this suggests:

How to handle this in ServiceStack, pls?

I was unable to get this work in RestSharp with FollowRedirects = false, so am trying with SS.

What do you mean by “handle this in ServiceStack”? Is this POST to a ServiceStack Service? If this request is to a 3rd Party API (i.e. non ServiceStack Service) you can use HTTP Utils to send HTTP requests.

See docs on how to send POST requests with HTTP Utils.

Yes, it’s a 3rd party service. How do I handle in HTTP Utils a POST redirect to a GET page?

Can you please provide the HTTP Utils code you’re using and the issue you’re running into?

I do not have any SS code yet, I am researching now how the SS is handling 302 code redirects. I am unable to find any code snippet covering this.

In RestSharp, the redirect is handled via the client’s FollowRedirects.

Is there any equivalent for this in SS?

HTTP Utils is a just thin abstraction over .NET Framework’s HttpWebRequest, you can use the optional requestFilter: available in each API to modify details of the Web Request like whether it should AllowAutoRedirect, e.g:

url.PostStringToUrl(requestFilter: req => req.AllowAutoRedirect = true);

But it’s true by default so this should not be needed.

Thank you very much.

How would I then implement the redirecting logic described in ?

std::string ComputeMethodForRedirect(const std::string& method,
                                     int http_status_code) {
  // For 303 redirects, all request methods except HEAD are converted to GET,
  // as per the latest httpbis draft.  The draft also allows POST requests to
  // be converted to GETs when following 301/302 redirects, for historical
  // reasons. Most major browsers do this and so shall we.  Both RFC 2616 and
  // the httpbis draft say to prompt the user to confirm the generation of new
  // requests, other than GET and HEAD requests, but IE omits these prompts and
  // so shall we.
  // See:
  if ((http_status_code == 303 && method != "HEAD") ||
      ((http_status_code == 301 || http_status_code == 302) &&
       method == "POST")) {
    return "GET";
  return method;

Have you tried sending a request yet? Please provide the code you’re using. Does the default behavior of HttpWebRequest not do what you want?

I will try tomorrow - it’s evening here.

I believe the default handling does NOT do this (RestSharp is using the same as SS apparently) - it reverts to POST.

The use case is essentially emulating a browser, not a standard REST API.

If you can think of a way how to implement GET redirect to a POST it would be appreciated,

Please read the available docs and use the API yourself first to make sure the default behavior doesn’t do what you want, if it doesn’t you can use the requestFitler to modify the HTTP request, e.g. set req.AllowAutoRedirect = false so it doesn’t follow redirects then you can inspect the Response Headers with responseFilter:, e.g. grab the Location Header and use it to send the new request that you want.

Thank you. How would you interpret the location // - see below the response?

The facts I know are:

  1. in a browser, the identical POST returns a sensible value
  2. the identical POST in RestSharp returns location //, and even with RestSharp’s FollowRedirects, RestSharp does not do anything. So I think the most likely explanation is the required transition to GET. However, I was unable to get this work in RestSharp.

I will try tomorrow with SS and will revert if it does not work.

I suspect a Location value of // is a Server API error. A url starting with / is relative to the domain if the POST was to a Location of / would redirect to so a // I’d expect to mean a redirect to which doesn’t look intentional.

Yes, it seems to be the case. Thank you again for your help!

My best assessment is that there is a RestSharp problem with cookies and redirects - see

Since SS is using the same underlying libs, I will try another technology now.

1 Like