The above link explains that POST/PUT should get a response of a 303 instead of 302, and since I am getting a 302 on a PUT, rest assured does not support redirects for that. If I do GET and receive a 302, all is well.
The above link explains that POST/PUT should get a response of a 303 instead of 302, and since I am getting a 302 on a PUT, rest assured does not support redirects for that. If I do GET and receive a 302, all is well.
Почему баг ? Это взято из спецификации HTTP клиента. По этому, если вы хотите что бы ваш тест заработал, то ваш сервис на этот POST request должен возвращать 303 , а не 302. Или же нужно тип этого запроса поменять на GET - не знаю что вам больше подходит.
Я искал определленый токен (“at”) в ответе таким способом
private Response findToken(Response response) {
while (response.cookie("at") == null) {
logger.logResponse(response, "Find Token");
cookies = mergeCookies(cookies, response.detailedCookies());
String url = response.then().extract().header("Location");
if (url == null) {
logger.error("Url for parse is null.");
throw new IllegalStateException("Url for parse is null.");
}
Map<String, String> params = parseParamsFromUrl(url);
response = with().spec(new RequestSpecBuilder()
.setBaseUri(url)
.addParams(params)
.setConfig(RestAssuredConfig.newConfig().redirect(RedirectConfig.redirectConfig().followRedirects(false)))
.addCookies(cookies)
.addHeader(HttpHeaders.ACCEPT, "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
.build())
.get();
}
return response;
}
Выдирал из ответа Location куда нас перенаправляют, делал merge куки (прокидывал куки от запроса к запросу) составлял новый запрос с нужными хедерами, посылал его и далее по кругу, пока не выполнится условие, у меня это занимало порядка 5 проходов по циклу.
А отказался от нативных редиретов, потому что, если вместе с редиректом приходит какая-то инфа, то ты ее просто теряешь, потому что на выходе у тебя лишь конечный response и нет возможности заглянуть в промежуточные.