I’m trying to access an API using Postman to get a response using basic authentication, but when I submit the data, it gives me the dreaded 400 error, which apparently indicates that some headers aren’t set up properly.
Here’s the API info:
Request
Endpoint: {loginUrl}
Data to submit: an email and a password
POST /login HTTP/1.1
Host: {baseUrl}
Accept: application/json
Content-Type: application/json
Content-Length: 68
{
"email": "{email}",
"password": "{password}"
}
And in response, I should get an encrypted token in form of JSON, instead I’m getting this error.
Here are the postman screenshots:
Am I missing something?
asked Jan 28, 2018 at 17:28
7
I also faced the same issue and i updated my postman header with the below image. And issue solved.
answered Aug 11, 2021 at 5:54
1
From the lack of details it’s difficult to offer a specific answer but I can offer something that you can try — The Request data you posted in the question looks like you should be adding:
{
"email": "{email}",
"password": "{password}"
}
In the Body section of the request but your images don’t show that you’ve added that to the Body on any request, you’ve added it as a Auth header instead, so remove that before trying again. I’m not sure of the need to add the Content-Length header as that will change for different username and password combinations in the payload or for the length of the response.
answered Jan 28, 2018 at 19:08
Danny DaintonDanny Dainton
21.6k6 gold badges58 silver badges73 bronze badges
In case anyone finds this helpful, I ran into the same issue and the culprit turned out to be missing headers. I knew I needed the "Content-Type": "application/json" header, which I already had in place, but I didn’t know that I was missing two other headers.
The solution for me was also adding the "Content-Length" and "Host" headers in Postman.
I see some others have questioned the need for the "Content-Length" header, but in my case, the minimum three needed were "Content-Type", "Content-Length", and "Host" or it would always fail.
answered Feb 25, 2022 at 20:03
cf512cf512
414 bronze badges
I faced a similar issue. it got resolved when i called my placeholder as a tuple.
answered Oct 5, 2022 at 10:02
1
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Go to ‘…’
- Click on ‘….’
- Scroll down to ‘….’
- See error
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem. Please make sure the screenshot does not contain any sensitive information such as API keys or access tokens.
App information (please complete the following information):
- App Type [e.g. Chrome App, Native App]
- Postman Version [e.g. 6.0.1]
- OS: [e.g. macOS High Sierra 10.13.2]
Additional context
Add any other context about the problem here.
@MuraliKrishna4550 You are going to have to give more information than this.
Can you please give us more details? Console Logs would be helpful so we can get an idea of what may be happening.
I am having the same problem.
Any POST request to any service running on any port on localhost never hits the service. It immediately errors out with a 400 Bad Request. I have included as much information as is relevant to the problem, the same request made of a valid hostname elsewhere works without issue.
MacOS 10.15.5
Postman 7.28.0 (Native App)
I recently updated Postman on a reboot and ever since I have experienced this problem, I have no issues reaching valid hostnames, it is just when I attempt to hit localhost that it nearly immediately gives a 400 and I do not see the request hit the locally running service that is being developed.
@gintohewoo The request does reach your locally running service that’s why it’s returning a 404 response.
Can you share what’s the request URL like? or, share steps that we can use to reproduce this issue locally?
Did you disable the Host request header? I see it’s missing from the attached console screenshot.
I am not sure how to disable the HOST request header.
I believe the host is missing because this request is going to localhost. I do see the host header entry when I hit the services running at a valid hostname, so perhaps this is the issue.
@gintohewoo Host header is attached to every request sent unless it’s disabled explicitly. Refer to the following screenshot and check if the Host field is disabled/unchecked.
Everything looks as it should on my end.
I have simply rolled back to an earlier version and things appear to be working now. Thank you for your assistance but I had to get this deployed by end of week this week, sorry I could not be of more help.
@hostaur Note that this setting is deprecated and will be removed in the future.
Can you share what’s the issue you are facing and got the need of turning this OFF?
I’m facing the same issue in Version 9.14.0 after the update. Where can I get the previous version of postman?
where is the problem reply as sson as possible urgent
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова.
Если вы хоть раз делали REST-запрос или изучали раздел инструментов разработчика в браузере, то наверняка видели код ответа из трех цифр, возвращенный в ответ на HTTP-запрос. Давайте поговорим о различных типах кодов ответа, которые можно получить в процессе тестирования API, и том, что они означают.
Ответы 100
Ответы уровня 100 означают, что запрос должен продолжаться. Наиболее частый тип такого ответа – это просто-напросто 100 Continue. Это может использоваться при объемных запросах, давая серверу возможность остановить большой запрос до того, как будет передан слишком большой объем данных. Возможно, при тестировании вашего API вы с этим не столкнетесь – сервер продолжит отвечать, завершит этот процесс «за кулисами» и выдаст ответ-200.
Ответы 200
Ответы уровня 200 обозначают успех запроса. Наиболее распространенный ответ – это 200 OK, который просто означает, что все прошло как ожидалось. Вот другие примеры запросов этого уровня:
201 Created – такой ответ означает, что в результате запроса создан некий новый ресурс. К примеру, GET-запрос может создать запись в логе, демонстрирующую дату, время и содержание запроса.
202 Accepted – этот ответ значит, что запрос был принят, но еще не завершен. Например, это изменение базы данных, которое нуждается в одобрении перед тем, как повлиять на базу непосредственно.
204 No Content – это значит, что запрос был успешно обработан, и не вернул никаких данных. Этот ответ может прийти на PUT-запрос, когда содержание изменилось, но разработчик не видел необходимости отдавать в ответе какие-то данные. Ответ 200 OK тоже может не возвращать данные, если так решил разработчик, но 204 не возвращает их никогда.
Ответы 300
Ответы уровня 300 говорят о перемещении ресурса. Наиболее частый из таких ответов – это 301 Moved Permanently. Этот ответ должен включать новый URL в заголовке, чтобы клиент понимал, куда в следующий раз обращаться с запросом.
Ответы 400
Ответы уровня 400 обозначают, что с запросом было что-то не так. Наиболее частый из них – 400 Bad Request, обычно применяемый, когда запрос неверно сформулирован или по какой-то причине неправилен. К примеру, в нем отсутствуют необходимые данные, или произошла ошибка валидации этих данных. Другие распространенные варианты ответов-400:
401 Unauthorized – обычно отдается, если у клиента нет соответствующей аутентификации для запроса, к примеру, токена JWT или куки.
403 Forbidden – отдается, если у клиента есть аутентификация, но нет прав на просмотр ресурса. К примеру, пользователь залогинен и может запрашивать свои данные, но не может запрашивать чужие.
404 Not Found – возвращается, если клиент запрашивает специфический ресурс, а сервер не может его найти. Например, запрашивается пользователь с ID 100, отсутствующий в базе данных.
409 Conflict – отдается, если запрос заставляет данные конфликтовать друг с другом. К примеру, клиент пытается осуществить POST-запрос для создания ресурса с ID, который уже используется.
Ответы 500
Ответы уровня 500 значат, что что-то пошло не так на серверной стороне. Чаще всего встречается ответ 500 Internal Server Error, использующийся для обозначения разнообразных проблем. Например, запрос пытался добавить запись в базу данных, которая не может обработать такую запись, потому что в ней слишком много символов, или у записи неверный тип. Другие ответы уровня 500 могут быть такими:
502 Bad Gateway – происходит, если сервер, отвечающий на запрос, должен сделать запрос к другому серверу, а другой сервер возвращает невалидный ответ.
503 Service Unavailable – такой ответ возвращается, если отвечающий сервер по какой-то причине недоступен. Он обычно более полезен, нежели общий ответ 500, потому что сигнализирует, что проблема с доступностью сервера, а не с базой.
Теперь, когда мы знаем, что значат коды ответов, давайте посмотрим на них предметно в нашей коллекции Postman PetStore! Если вы еще не создали, см. предыдущую статью. Кликните на первом запросе в коллекции: Add Pet. Под URL запроса нажмите на «тесты». В правой стороне окна будет список сниппетов кода, которые можно использовать для создания правил. Проскролльте список вниз, пока не найдете сниппет «Status code: Code is 200», и нажмите на него. Это автоматически добавит правило в поле теста, который выглядит вот так:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
Секция «Status code is 200» – это название вашего теста. Секция «pm.response.to.have.status(200)» – это ожидаемый результат.
Нажмите кнопку «Save», а затем «Send». В нижней части страницы вы увидите секцию «Test Results» с «1/1» после названия секции. Это значит, что был запущен один тест, и один тест прошел успешно. Если нажать на ссылку «Test Results», вы увидите «PASS» и «Status code is 200» в секции ответа. Вы успешно добавили правило к вашему запросу!
Давайте посмотрим, как выглядит упавшее правило. Чтобы заставить его упасть, просто измените тело правила на:
pm.test("Status code is 202", function () {
pm.response.to.have.status(202);
});
Теперь мы ожидаем ответа 202, а не 200. Снова запустите запрос, и вы увидите «0/1» рядом со ссылкой «Test Results». Нажмите на ссылку, и в секции ответа вы увидите «FAIL» и «Status code is 202». Это значит, что тест по имени «Status code is 202» упал.
Снова поменяйте тест, чтобы он ожидал ответа 200, и добавьте правило ко всем запросам коллекции, кроме запроса «Verify Delete Pet». Этот запрос ищет запись, которая больше не существует, поэтому там мы не ожидаем ответа 200. Вместо этого мы должны получить 404 Not Found. Давайте добавим это ожидание в секцию тестов:
pm.test("Status code is 404", function () {
pm.response.to.have.status(404);
});
Нажмите на кнопку «Save» и сохраните тест.
Если вы прогоните этот запрос до запроса Delete Pet, то тест упадет, потому что животное с ID 100 все еще существует. Но если вначале запросить Delete Pet, а затем Verify Delete Pet, то тест будет пройден успешно, потому что животного с ID 100 больше нет в базе данных.
Теперь у нас есть правила для всех наших запросов. Давайте запустим прогон всей коллекции! Наведите курсор на название коллекции Pet Store, и нажмите на шеврон >, который появится справа. Кликните по кнопке «Run», и откроется Collection Runner. Нажмите на имя вашей коллекции, а затем – на кнопку «Run Pet Store». Вы увидите, как запускаются (и успешно выполняются) все ваши тесты, причем очень быстро! Окно результатов будет выглядеть примерно так:
В верхней части окна вы увидите, что шесть ваших тестов прошло успешно, и ни один не упал. Вы увидите названия всех созданных запросов, имена тестов для каждого запроса, и индикатор «PASS».
Обсудить в форуме