Performing a POST request to the URL returning HTTP status code 301 (moved permanently), redirected request is changed into a GET without params from original POST request.
@FormUrlEncoded
@POST("device/register")
Call<ServerResponse> sendToken(@Field("token") String token);
HTTP server logs:
89.67.XXX.XXX - - [20/Mar/2016:22:47:08 +0100] "POST /api/v1/device/register HTTP/1.1" 301 572 "-" "okhttp/3.2.0"
89.67.XXX.XXX - - [20/Mar/2016:22:47:08 +0100] "GET /api/v1/device/register/ HTTP/1.1" 200 306 "-" "okhttp/3.2.0"
Problem occurs on version 2.0.0 as well as 2.0.0-beta4
For that your server should return 308, not 301.
https://tools.ietf.org/html/rfc7538
@swankjesse: Status code 301 is not returned due to the code of API developers in this case. That's just default Apache2 behavior in this situation (here when it needs last "/" in the URI) to properly handle the request. This problem does not occur when requesting the same address from tools like Postman, that just redirect to a new URI keeping the original request instead of generating a blank GET.
Additionally take a look at the note @ https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
You can use an Interceptor installed as a network interceptor on the
OkHttpClient to change 301's into 308's so that it's handled properly by
OkHttp.
On Mon, Mar 21, 2016 at 9:46 AM JerzyPuchalski [email protected]
wrote:
Status code 301 is not returned due to the code of API developers in this
case. That's just default Apache2 behavior in this situation (here when it
needs last "/" in the URI) to properly handle the request. This problem
does not occur when requesting the same address from tools like Postman,
that just redirect to a new URI keeping the original request instead of
generating a blank GET.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/square/retrofit/issues/1690#issuecomment-199287085
Most helpful comment
@swankjesse: Status code 301 is not returned due to the code of API developers in this case. That's just default Apache2 behavior in this situation (here when it needs last "/" in the URI) to properly handle the request. This problem does not occur when requesting the same address from tools like Postman, that just redirect to a new URI keeping the original request instead of generating a blank GET.
Additionally take a look at the note @ https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2