subdomain - Respuesta "No se pudo obtener ninguna respuesta" al utilizar cartero con subdominio
postman (18)
Estoy usando Postman para probar una API que tengo, todo está bien cuando la solicitud no contiene un subdominio, sin embargo, cuando agrego un subdominio a la URL obtengo esta respuesta.
No se pudo obtener ninguna respuesta
Se produjo un error al conectarse a http://subdomain.localhost:port/api/
Por qué pudo haber sucedido esto:
El servidor no pudo enviar una respuesta: asegúrese de que el servidor esté funcionando correctamente
Se están bloqueando los certificados SSL autofirmados: solucione esto desactivando ''Verificación de certificado SSL'' en Configuración> General
Proxy configurado incorrectamente Asegúrese de que el proxy esté configurado correctamente en Configuración> Proxy
Tiempo de espera de solicitud: cambie el tiempo de espera de solicitud en Configuración> General
Si copio la misma URL del cartero y la pego en el navegador obtengo una respuesta adecuada, ¿hay algún tipo de configuración que deba hacer para que el cartero funcione con subdominios?
Al obtener el siguiente error,
necesitas hacer lo siguiente.
Paso 1: en Cartero, haga clic en el icono de llave inglesa, vaya a configuración y luego vaya a la pestaña Proxy.
Paso 2: crea un Proxy personalizado. Este artículo explica cómo crear un proxy personalizado. Después de crear el Proxy personalizado, asegúrese de desactivar el botón de alternancia Proxy. Puse 61095 para el servidor proxy y funcionó para mí.
Paso 3 :
Éxito
Desmarcar el proxy y la verificación del certificado SSL no funcionó para mí.
Desarmar variables de entorno PROXY hizo el truco.
export http_proxy=
export ftp_proxy=
export https_proxy=
Cambie al directorio donde está instalado Postman y luego:
./Postman
Después de todos los métodos anteriores, como DESACTIVAR la verificación del certificado SSL, activar SÓLO Usar Proxy del sistema y eliminar las variables de entorno del sistema HTTP_PROXY y HTTPS_PROXY, funcionó.
Nota: Tuve que reiniciar la aplicación Postman, ya que se modificaron las variables de entorno.
En mi caso, MVC no pudo serializar los resultados (accidentalmente usé un modelo en lugar de DTO). Me depuré para pasar una cadena simple, que funcionó. Una vez que arreglé la serialización, todo surgió.
Hola, este problema está resuelto para mí.
configuración -> general -> Requesttimeout en ms = 0
Ninguna de estas soluciones funciona para mí.
El cartero no envía ninguna solicitud al servidor porque el cartero no encuentra el host.
Entonces, si modifica su / etc / hosts a
127.0.0.1 localhost
127.0.0.1 subdomain.localhost
Esto funciona para mi.
Para mí fue el http: // localhost en lugar de https: // localhost .
Para mí, el problema era que la
Content-Length
del
Content-Length
era demasiado grande.
Puse el contenido del cuerpo en NotePad ++ y conté los caracteres y puse esa figura en
PostMan
y luego funcionó.
Sé que no responde directamente por qué el subdominio del operador no funcionaba, pero podría ayudar a alguien.
Para mí, esa ruta a la que estaba llamando en mi servidor de nodo no devolvía nada. Agregando
return res.status(200).json({
message: ''success!'',
response: ''success!''
});//
a la ruta que estaba llamando resolvió el problema.
Para mí, lo que funcionó fue agregar
127.0.0.1 subdomain.localhost
a mi archivo de host.
En OSX que era / etc / hosts.
No estoy seguro de por qué eso era necesario, ya que podía llegar al subdominio desde Chrome.
Se me ocurrió esta solución
Si recibe un mensaje de "No se pudo obtener ninguna respuesta" de las aplicaciones nativas de Postman al enviar su solicitud, abra la Consola de Postman (Ver> Mostrar consola de Postman), vuelva a enviar la solicitud y verifique si hay registros de errores en la consola.
Gracias a numaanashraf
Si todos los métodos anteriores no funcionan, verifique las variables de entorno y asegúrese de que los siguientes entornos no estén configurados. Si están configurados y ninguna otra aplicación los necesita, elimínelos.
HTTP_PROXY
HTTPS_PROXY
link referencia
Tuve el mismo problema. Fue causado por una nueva línea al final del valor del encabezado "Autorización", que configuré manualmente al copiar y pegar el token del portador (que accidentalmente contenía la nueva línea al final)
Usted mencionó que está utilizando un certificado CER.
Según la página del cartero en certificados.
Elija su archivo de certificado de cliente en el campo de archivo CRT. Actualmente, solo admitimos el formato CRT. La compatibilidad con otros formatos (como PFX) llegará pronto.
El nombre de la extensión CER, CRT no hace que el certificado sea ese tipo de certificado, pero estos son los nombres de extensiones exceptuados.
CER es un certificado X.509 en forma binaria, codificado DER.
CRT es un certificado binario X.509, encapsulado en codificación de texto (base-64).
Puede usar OpenSSL para cambiar un archivo CER a un archivo CRT. No he tenido buena suerte con eso, pero se ve así.
openssl x509 -informar PEM -in certificate.cer -out certificate.crt
o
openssl x509 -informar DER -en certificado.cer -out certificado.crt
En mi caso, eran espacios invisibles que cartero no reconoció, la cadena de texto anterior se muestra como sin espacios en cartero. Deshabilité la validación del certificado SSL y el Proxy del sistema incluso probé la extensión Chrome de cartero (que está a punto de desaprobarse), pero cuando descargué e intenté Insomnia y me dio esos puntos rojos en el lugar donde estaban esos espacios, debe haber llegado allí durante la copia /pegar
Cartero para Linux versión 6.7.1 - Ubuntu 18.04 - linux 4.15.0-43-generic / x64
Tuve el mismo problema y, por casualidad, reemplacé
http://localhost
con
http://127.0.0.1
y todo funcionó.
Mis
etc/hosts
tenían las entradas adecuadas para
localhost
y
https://localhost
solicitudes de
https://localhost
siempre funcionaron como se esperaba.
No tengo idea de por qué cambiar
localhost
por
http
con
127.0.0.1
resolvió el problema.