Запрос POST обрабатывается как GET в среде Heroku
у меня странный случай. У меня есть приложение RoR, которое предоставляет REST API, к которому я подключаюсь из приложения Java.
Я разрабатываю RoR локально и развертываю его в среде Heroku.
независимо от того, как (я пытался из Java-приложения, клиента Mozilla REST и т. д.) Я пытаюсь отправить POST HTTP-запрос, который должен обрабатываться действием create в контроллере api. На localhost - все работает, как ожидалось. На Heroku production env-запрос POST рассматривается как обычный ПОЛУЧИТЬ.
вот мои маршруты для этого ресурса:
api_v1_items GET /api/v1/items(.:format) api/v1/items#index {:format=>:json}
POST /api/v1/items(.:format) api/v1/items#create {:format=>:json}
api_v1_item GET /api/v1/items/:id(.:format) api/v1/items#show {:format=>:json}
PATCH /api/v1/items/:id(.:format) api/v1/items#update {:format=>:json}
PUT /api/v1/items/:id(.:format) api/v1/items#update {:format=>:json}
DELETE /api/v1/items/:id(.:format) api/v1/items#destroy {:format=>:json}
поэтому я пытаюсь сделать запрос POST на /api/v1/items
прохождения всех необходимых параметров.
в localhost ответ правильный:
Started POST "/api/v1/items?token=l4XOHrhDApPqTp1u4TxBjQ" for 127.0.0.1 at 2014-05-15 22:11:49 +0200
Processing by Api::V1::ItemsController#create as JSON
Parameters: {"height"=>10.0, "item_name"=>"Super item", "width"=>20.0, etc...
однако та же просьба уволить Героку ее рассматривалась как GET:
2014-05-15T20:27:58.137541+00:00 app[web.1]: Started GET "/api/v1/items?token=iEdDkDLiDUlWi0mDbr6XYw" for 89.74.57.51 at 2014-05-15 20:27:58 +0000
2014-05-15T20:27:58.223620+00:00 app[web.1]: Processing by Api::V1::ItemsController#index as JSON
есть идеи? Конечно, оба репозитория синхронизированы. Проверял несколько раз.
Это очень странно... может быть, какая-то магия тайника Героку?
4 ответов
HTTP / 1.1 301 перемещен навсегда
301 редирект не в Heroku магии. Ваш DNS (или, возможно, ваше приложение), вероятно, пересылает все запросы apex (mydomain.com) к www
поддомен.
предпочтительно использовать поддомены:
Я испытал аналогичную ошибку, когда не использовал пользовательский домен только из-за легко упущенной ошибки: я использовал heroku.com вместо herokuapp.com
неправильно: http://my-app.heroku.com
право: http://my-app.herokuapp.com
Я подозреваю, что это очень похоже на проблему, упомянутую в Catsby это.
Ну, я попробовал завить, и оказалось, что ошибка глупая.
я размещал в http://mydomain.com, где он маршрутизируется как GET. Когда я стреляю в http://www.mydomain.com - это работает.
в Heroku магии.
ниже скручиваемость и результаты для вашей ссылки. Может быть, кто-то сможет объяснить, почему это работает так...
сообщение на mydomain.com
curl -v -H "Accept: application/json" -H "Cont"width":20.0,"item_desc":"The super item","std_pack":40,"sku":"A1004","depth":20.0}}' http://mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
* Adding handle: conn: 0x7fe70b803000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe70b803000) send_pipe: 1, recv_pipe: 0
* About to connect() to mydomain.com port 80 (#0)
* Trying 78.46.51.229...
* Connected to mydomain.com (78.46.51.229) port 80 (#0)
> POST /api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw HTTP/1.1
> User-Agent: curl/7.30.0
> Host: mydomain.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 174
>
* upload completely sent off: 174 out of 174 bytes
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 15 May 2014 21:20:58 GMT
* Server Apache is not blacklisted
< Server: Apache
< Location: http://www.mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
< Content-Length: 273
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw">here</a>.</p>
</body></html>
* Connection #0 to host mydomain.com left intact
пост в www.mydomain.com
Maciejs-MacBook-Pro:merchbag maciejsimm$ curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"item":{"height":10.0,"item_name":"Super duper item","width":20.0,"item_desc":"The super","std_pack":40,"sku":"A1005","depth":20.0}}' http://www.mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
* Adding handle: conn: 0x7fc191003000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fc191003000) send_pipe: 1, recv_pipe: 0
* About to connect() to www.mydomain.com port 80 (#0)
* Trying 50.17.185.176...
* Connected to www.mydomain.com (50.17.185.176) port 80 (#0)
> POST /api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.mydomain.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 133
>
* upload completely sent off: 133 out of 133 bytes
< HTTP/1.1 201 Created
< Cache-Control: max-age=0, private, must-revalidate
< Content-Type: application/json; charset=utf-8
< Date: Thu, 15 May 2014 21:24:17 GMT
< Etag: "41231ae0f50a604cd7316a014d19b3f2"
* Server WEBrick/1.3.1 (Ruby/2.0.0/2014-05-08) is not blacklisted
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-05-08)
< Set-Cookie: request_method=POST; path=/
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: ba05dd74-bf52-47d5-b8a9-d0516aff5804
< X-Runtime: 0.020289
< X-Ua-Compatible: chrome=1
< X-Xss-Protection: 1; mode=block
< Content-Length: 234
< Connection: keep-alive
<
* Connection #0 to host www.mydomain.com left intact
{"id":15,"partner_id":1,"sku":"A1005","item_name":"Super duper item","item_desc":"The super","std_pack":40,"height":10,"width":20,"depth":20,"image":null,"created_at":"2014-05-15T21:24:17.753Z","updated_at":"2014-05-15T21:24:17.761Z"}
У меня была такая же проблема при отправке запроса POST в heroku с использованием HTTP вместо HTTPS. Каждый раз, когда heroku направлял мои запросы POST Как запросы GET. Как только я обновил url-адрес для использования HTTPS, мои запросы POST были направлены heroku как сообщения, а не получает, решая проблему. Проблемы перенаправления, упомянутые в предыдущих сообщениях, вероятно, являются основной причиной проблемы, с которой я столкнулся.