2016-11-09 6 views
0

Я создал API в консоли apigateway, который выступает в качестве http-прокси-сервера для моего бэкэнд-сервера, на котором запущено приложение Java. Мы развернули api, создали собственный домен для его размещения через облачный режим. Теперь, когда я использую новые URL cloundfront в моем веб-приложении, некоторые из API не возвращаются немедленно. Такое же поведение можно заметить даже с завитком командойНепоследовательные ответы от aws apigateway

curl -v -H "Cookie:session_token=llzAwur3FZS78po6b21FEgvXzDUFY3" https://xyz.execute-api.us-east-1.amazonaws.com/test/api/folder/roo 

же API конечных точками будет иметь различное время отклика (иногда около 1 вторых, а иногда это может быть несколько секунд). Иногда это время тоже. Журнал запросов на серверный сервер (причал) показывает, что ответ отправляется мгновенно. Как мы можем исследовать, что происходит с нашим развертыванием APIgateway?

Например, у меня есть два ответа от шлюза. Плохая

< HTTP/1.1 504 Gateway Time-out 
< Content-Type: text/html 
< Content-Length: 669 
< Connection: keep-alive 
< Server: CloudFront 
< Date: Fri, 11 Nov 2016 12:27:14 GMT 
< X-Cache: Error from cloudfront 
< Via: 1.1 xyz.cloudfront.net (CloudFront) 
< X-Amz-Cf-Id: Wfjk3bqdwhAbFQhzerMd0DJ5t_2xAF6E_NUTvqif1p9cb9E-jy0GUw== 
< 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> 
<TITLE>ERROR: The request could not be satisfied</TITLE> 
</HEAD><BODY> 
<H1>ERROR</H1> 
<H2>The request could not be satisfied.</H2> 
<HR noshade size="1px"> 
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. 
<BR clear="all"> 
<HR noshade size="1px"> 
<PRE> 
Generated by cloudfront (CloudFront) 
Request ID: 881Muk_9up7A0phYvmmchNkYWj16yFCsthuKFivS2vbtpULtCk9lnw== 
</PRE> 
<ADDRESS> 
</ADDRESS> 
* Connection #0 to host ulj2mxzix6.execute-api.us-east-1.amazonaws.com left intact 
</BODY></HTML> 

И this-- один

< HTTP/1.1 200 OK 
< Content-Type: application/json;charset=UTF-8 
< Content-Length: 1839 
< Connection: keep-alive 
< Date: Fri, 11 Nov 2016 12:28:43 GMT 
< x-amzn-Remapped-Connection: keep-alive 
< x-amzn-Remapped-Content-Length: 1839 
< x-amzn-Remapped-Date: Fri, 11 Nov 2016 12:28:43 GMT 
< x-amzn-Remapped-Server: nginx/1.4.6 (Ubuntu) 
< x-amzn-RequestId: 621bff67-a80a-11e6-bb0a-1bc973821ef5 
< X-Cache: Miss from cloudfront 
< Via: 1.1 1d43f56d3213a63608863fd0e49585b9.cloudfront.net (CloudFront) 
< X-Amz-Cf-Id: ZGwu2NAXKCouMssDjHwSnjyWXe4OFukmeyL7nzC_Y4Lz6QnixdhbEg== 

EDIT Разрешение хорошее /:

Как уже упоминалось в ответе ниже я должен был отключить заголовок, чтобы получить длину содержимого в заголовки ответов. Я использую Spring MVC для реализации REST API и добавление ниже фильтра, кажется, сделал Хитрость

<filter> 
     <filter-name>bufferFilter</filter-name> 
     <filter-class>org.springframework.web.filter.ShallowEtagHeaderFilter</filter-class> 
    </filter> 
    <filter-mapping> 
     <filter-name>bufferFilter</filter-name> 
     <url-pattern>/api/*</url-pattern> 
    </filter-mapping> 
+0

Вы размещаете распределение CloudFront перед шлюзом API? –

+0

Да. Я создал собственный домен с сертификатами SSL. Как я уже говорил, команда curl иногда работает, но в основном висит или требуется около минуты, чтобы вернуться. Любая помощь в решении моей проблемы будет оценена по достоинству. Спасибо –

+0

Вы создали собственный домен и указали на свой собственный дистрибутив CloudFront, а затем указали на API-шлюз? –

ответ

0

Эта ошибка обычно возникает, когда ваш бэкенд использует Transfer-Encoding: chunked.

Мы нажимаем обновление службы, чтобы устранить эту проблему, но в то же время вы можете отключить закодированную кодировку с вашего сервера.

+0

Спасибо. Я думаю, что сделал трюк –

Смежные вопросы