Errores, fallos, preguntas - página 2706

 
Sergey Dzyublik:

Ese es el problema, no hay un libro de registro para la pestaña de Errores en ME.

Mi falta de atención...

 

¿qué es el código 556?

30 gráficos con EA, en la compilación algunos no se recuperaron con este código, otros con éxito.

 
Igor Zakharov:

¿qué es el código 556?

30 gráficos con EA, en la compilación algunos no se recuperó con este código, el otro con éxito.

Error al abrir el archivo dip.ex5

Mostrar el registro completo, no un trozo de pantalla

 
Lugares para incluir registros tratará de añadir
 
Slava:

Error al abrir el archivo dip.ex5

Mostrar el registro completo, no un trozo de pantalla

ver anexo.

Archivos adjuntos:
20200415.zip  5 kb
 

¿Alguien puede decirme cómo amigar los sockets TLS con el servidor echo? Tomé el código fuente del ejemplo y añadí las cabeceras. En el puerto 80 hace una actualización, pero en el 443 se conecta y obtiene un certificado, pero luego no puede leer nada de las cabeceras. Si se ejecuta bajo el depurador, se puede ver queSocketIsReadable devuelve un número similar, como 245, pero SocketTlsRead falla por tiempo de espera sin devolver nada. Aparentemente, se requieren conocimientos sagrados de MQ.

Archivos adjuntos:
 

Bug ME (build 2380) firma incorrecta del parámetro de la plantilla de funciones en la descripción de errores y en la información de los parámetros.

template<typename T>
class A{};

class B{
public:  
   template<typename T>
   static void test(A<T> &, A<int>* = NULL){
      int x = 1 / 0;                       //'0' - division by zero |  in template 'void B::test(B:: A<T>&,A<int>*)' specified with [T=long]
   }
};

void OnStart(){
   A<long> a;
   B::test(a);                             // Parameter info: void test([unknown] &, [unknown] *=NULL)
}
 
Stanislav Korotky:

¿Alguien puede decirme cómo amigar los sockets TLS con el servidor echo? Tomé el código fuente del ejemplo y añadí las cabeceras. En el puerto 80 hace una actualización, pero en el 443 se conecta y obtiene un certificado, pero luego no puede leer nada de las cabeceras. Si se ejecuta bajo el depurador, se puede ver que SocketIsReadable devuelve un número similar, como 245, pero SocketTlsRead falla por tiempo de espera sin devolver nada. Aparentemente, se requieren conocimientos sagrados de MQ.

Tampoco pude obtener una matriz de respuesta de bytes usando HTTPRecv, para el posterior análisis del protocolo.
Falla en el tiempode espera, porque el ping pong no está organizado, pero para organizarlo necesitas obtener primero la respuesta en bytes del servidor, y la propia funciónHTTPRecv contiene el tiempo de espera.
Pero por alguna razón HTTPRecv no analiza esta respuesta de bytes.

 
Roman:

Tampoco he conseguido obtener una matriz de respuesta de bytes utilizando HTTPRecv para el posterior análisis del protocolo.
Falla en el timeout, porque el ping pong no está organizado, pero para organizarlo necesitas obtener primero la respuesta en bytes del servidor, y la propia funciónHTTPRecv contiene timeout.
Pero por alguna razón HTTPRecv no analiza esta respuesta de bytes.

Es sólo la conexión en sí misma. Todavía no hay ping - puede ocurrir más tarde en el protocolo websocket. El problema se produce en la cabecera de respuesta del servidor cuando tiene que acusar recibo de la actualización. Cuando no se utiliza TLS, se conecta normalmente. Pero también con TLS, parece que llega la cabecera a la terminal, pero no vuelve deSocketTlsRead.

 
Stanislav Korotky:

Esto es sólo la conexión en sí. Todavía no hay ping - puede ocurrir más tarde en el protocolo websocket. El problema se produce en la cabecera de la respuesta del servidor cuando tiene que acusar recibo de la actualización. Cuando no se utiliza TLS, se conecta normalmente. Pero también con TLS, parece que la cabecera llega al terminal, pero no vuelve de SocketTlsRead.

Sí, ya veo lo que quiero decir.
Sí, efectivamente en tu código, en el puerto 80 vuelve el encabezado, en el 443 no.
Volví a revisar tu código y no vi la funciónSocketTlsHandshake allí.
Su código no realiza un apretón de manos. Esta puede ser la razón.
Aunque la ayuda de esta función dice que no es necesaria si se conecta al puerto 443.
Así que es raro en general.

UPD:
No importa cómo ponga la cabecera de la petición, sigue dando el error

ERR_NETSOCKET_IO_ERROR 5273  Ошибка отправки/получения данных из сокета

O

HTTP/1.1 400 Bad Request

¿Quizás el desarrollador prohibió recibir la actualización a TLS?


UPD:
No hay error con su cabecera, pero tampoco hay cabecera de respuesta.
En la funciónHTTPRecv pon un print para ver lo que entra.

result += CharArrayToString(rsp, 0, rsp_len, CP_UTF8);
Print(result);

Sólo imprime un carácter H
Este carácter me hace pensar que es la primera letra de la cabecera de la respuesta,
y no imprime el resto de la cabecera por alguna razón.

Estimados desarrolladores, ¿podrían decirnos qué hacer?
¿Es una restricción intencionada o es un error de TLS?
Llevo mucho tiempo luchando con este problema, sin éxito.

Razón de la queja: