Lectura: cosas, desde/con los esports... sólo por contarlo

Si no tienes tiempo, ve a otro hilo, que viene una parrafada. De verdad, cuando tengas tiempo libre y ganas de reírte aunque tampoco es que cuente chistes.

A ver, después de semanas detrás de el problema, que más que detrás, saber qué demonios me estaba pasando, porque sólo pasaba en esta web, lo he encontrado, pero seguramente será culpa mía, y por eso no decía nada, como lo de la caché¹, por usar software obsoleto (si antes 4 años en la red era un siglo, ahora debe ser un milenio), pero tengo que contarlo, no porque le pongas solución, ya sabes que soy ese bicho raro que va sin condón, digo..., sin JavaScript por la vida, junto con otras malas prácticas, y al final hay que asumir cosas.

El caso es que, más o menos, desde hace ya un par de meses tenía un retardo en la maquetación CSS en la web cuando entraba. Una vez que navegaba y se "cacheaba"¹ ya se maquetaba bien. No ocurría siempre que entraba, que tiene más gracia, así que probar otros navegadores, tampoco me sacaba de la duda, y era extremadamente mosqueante, porque yo toco cosas, como todo el mundo y todo el rato pensando, ¿qué habré hecho? y, por qué no, ¿qué habrá hecho este melado :-P?

Al final, que si apareció el service worker de los esports (algún día nos contarás para qué :-?) ¿será eso?; que si apareció un interludio en la web cuando estás X tiempo sin navegar..., con los esports... ¿será eso?; que si se me ocurre hoy salvar la web (por qué demonios no lo haría el primer día) para ver si es que el CSS estaba al final de la página (mala práctica, pero oye, hay páginas que lo hacen) aunque ya había mirado y remirado, pero como el HTML de EOL no tiene formato (one loooooong line, how I hate it in programming... (ya sí, que lo copiase y pegase en un wysiwyg, pero me daba pereza)), igual me perdía algo y... bueno, en la página había algo de esports, aunque esa no era la cuestión en sí, pero ya de paso capturo el tráfico... y vuelta a los esports (cabecera Link)...

¿Os ha dado fuerte con los esports? Mira que no visito el subportal de esports, pero está hasta en la sopa. Lo del interludio, con la imagencita, no te voy a negar que me saca de quicio (sí, sólo se ve si vas por la vida sin JS). Que sí, que llevo tiempo sin cargar una página y soy muy lento leyendo, pero leches, que no seas cansa, página del carajo, :P si a mi los esports me importan un pimiento.

Bueno, pues la clave estaba al guardar la página. ¿Qué he descubierto?, pues que cuando el servidor envía la cabecera HTTP Link, que no es siempre, al navegador le da hipo y hace algo tal que:
<html>
<head>
<metas>
<script>
<img>, como no, de los esports, que está referenciado en la cabecera Link
</head>
<body>
<algunos meta que deberían ir en la cabecera>
<link> el link con el CSS de la web
se acaban el resto de cosas que tendrían que ir en la cabecera
.
.
.
el resto de la web ya normal


Y eso hace que al estar el CSS donde no debería, es decir, fuera de la cabecera, el CSS no se carga hasta que el body ha cargado. Y sólo pasa cuando se envía la cabecera Link de los esports.

¿Y la paradoja? que cuando inspecciono el tráfico y miro qué datos se reciben... la página está bien grrmppf

Así que supongo que será un bug mío, pero en Mozilla no he encontrado este bug. Aunque es cachondo ver como hace unos años pedían que quitasen el soporte a la cabecera Link, porque nadie lo utilizaba y luego que lo reintroduzcan. No hay quien los entienda Imagen

- Yo aquí, diría, y no lo pido, aunque lo digo —de eso trataba esto—, ¿es necesaria tanta basurilla de los esports [que a mí me da problemas]?
- Y tú dirías, actualiza el navegador, Die Hard user —y yo te daría la razón, pero ese es otro tema.
- Pero, ¿y el interludio?, ¿por qué el interludio con la dichosa imagencita de los esports?, de verdad, ¿a santo de qué tanto esports? Es que ya aburre.

Si yo veo normal, que queráis hacer tracking de la gente, o mantener vivo el service worker, o lo que sea, pero hombreeeeee.

Ains, en fin.

Bueno, esa es la historia de mis 2 últimos meses, más o menos, en EOL, espero que te hayas entretenido leyendo esto, tanto como yo intentando averiguar la causa, salvo que yo más que entretenido estaba un tanto escamado :P y la verdad es que saber la causa, tampoco me alivia, porque va a seguir pasando.

¡Viva los esports! (a quien le gusten)




¹ Cosas de la cache el SSL/TLS y la cabecera no-cache
Las cookies de "www.elotrolado.net" solo se pueden leer de "www.elotrolado.net". Pero ahora el jefe dice que quiere crear una nueva web en "esports.elotrolado.net" y que el login se comparta, pero "esports.elotrolado.net" no recibe las cookies que ya hay en "www", por razones de seguridad estándar de los navegadores. Oops, ¿ahora qué?

Mi solución (y, después me enteraría, la del resto de Internet, lo he visto hacer por ejemplo en los SSO de Google y Microsoft) fue que cuando "www" envíe una cookie nueva al usuario se genere una petición que copie la misma cookie en el dominio "esports". Esto se hace con una petición (de cualquier cosa, no importa) al dominio de destino y que este ponga la cookie donde debe. Para evitar sorpresas, el dominio de destino verifica que la cookie esté firmada correctamente antes de continuar. Luego, para evitar el clásico icono de imagen rota, responde con un GIF transparente de 1x1 de 26 bytes. Podría responder con una foto de @[erick] saltando a la comba, pero pensé en los usuarios móviles y lo hice lo más pequeño posible manteniéndome en la "legalidad" (una respuesta vacía sería menor pero inválida como imagen).

¿Por qué meter la URL de la petición "cruzada" en lo alto del HTML donde se supone que no debería estar? Porque cuando estaba en su sitio, al final de la página, la gente que cargaba la página y rápidamente la abandonaba, no daba tiempo al navegador al hacer la petición y, a efectos de login, cuando entraba en esports se perdía el login (y en www también porque esports iniciaba otra petición cruzada que machacaba a la de www con la cookie de usuario anónimo).

¿Por qué una cabecera Link en la respuesta HTTP? Para intentar que la petición se haga lo antes posible.

¿Por qué código JS si solo hay una imagen? Para reintentarlo pasado un tiempo en caso de fallar la petición (paquetes perdidos, error momentáneo del servidor...).

Mi consejo para cualquiera que tenga alergia a este sistema es que bloquee las peticiones que empiezan por /rpc.php?m=isb en su bloqueador favorito, con el cual estoy seguro que ya cuentan. Resolverá todos los problemas y, si no se visita esports, no causará ninguno nuevo.

Ah. No hay ningún service worker en todo este sistema, no sé dónde has visto uno. El único que tenemos se usa para las notificaciones push.
melado escribió:Las cookies de "www.elotrolado.net" solo se pueden leer de "www.elotrolado.net". Pero ahora el jefe dice que quiere crear una nueva web en "esports.elotrolado.net" y que el login se comparta, pero "esports.elotrolado.net" no recibe las cookies que ya hay en "www", por razones de seguridad estándar de los navegadores. Oops, ¿ahora qué?

Mi solución (y, después me enteraría, la del resto de Internet, lo he visto hacer por ejemplo en los SSO de Google y Microsoft) fue que cuando "www" envíe una cookie nueva al usuario se genere una petición que copie la misma cookie en el dominio "esports".

Esto se hace con una petición (de cualquier cosa, no importa) al dominio de destino y que este ponga la cookie donde debe. Para evitar sorpresas, el dominio de destino verifica que la cookie esté firmada correctamente antes de continuar.


Si yo sé que me meto donde no me llaman, pero..., digo yo, no sé, ¿por qué no poner el Host de la cookie a .elotrolado.net y nos olvidamos de historias raras, que para eso es posible con un simple puntito .?

Que está puesta para los Google Ads, no sé por qué no para esto. Que serán razones técnicas, como con otras cosas, pero, ozú.

Es que me estás contando unas historias para no dormir para una cookie inter-subdominios :-O (que no es inter-dominios)...., que, ya, que me estoy metiendo en cosas que no me atañen, pero es que lo veo tan fácil desde mi posición :-? Y tan complicado te veo contarlo.

A no ser que sea preocupante el que los clientes os bombardeen con cookies no solicitadas cuando, por ejemplo, se descarguen los avatares en download.elotrolado.net, por ejemplo, y eso suponga mucho tráfico de descarga (o tráfico recibido, como lo quieras llamar) al servidor.

O que se suponga un problema a cv.elotrolado.net, que, por cierto, siempre hay que hacer login cada X tiempo (que tampoco lo veo mal, es una apreciación).

melado escribió:Luego, para evitar el clásico icono de imagen rota, responde con un GIF transparente de 1x1 de 26 bytes. Podría responder con una foto de @[erick] saltando a la comba, pero pensé en los usuarios móviles y lo hice lo más pequeño posible manteniéndome en la "legalidad" (una respuesta vacía sería menor pero inválida como imagen).

¿Por qué meter la URL de la petición "cruzada" en lo alto del HTML donde se supone que no debería estar? Porque cuando estaba en su sitio, al final de la página, la gente que cargaba la página y rápidamente la abandonaba, no daba tiempo al navegador al hacer la petición y, a efectos de login, cuando entraba en esports se perdía el login (y en www también porque esports iniciaba otra petición cruzada que machacaba a la de www con la cookie de usuario anónimo).


Sí, vale, pero a ver, es que, ¿una imagen?.

No digo que por ejemplo ayudase a mi caso a que el navegador no le de hipo, si tiene un bug, tiene un bug, (y no voy a ser tan egocentrista de, venga hazlo por mí, pero me permito el lujo de comentarlo), porque no tengo otros sitios con los que probar y confirmártelo, pero es que Link, al final, atañe a la cabecera (<head> si bien W3 no dice a las claras que el elemento se añada a <head>), de una u otra forma, así que, ¿por qué no tirar por la tangente y en vez de pedir una imagen, pedimos un archivo CSS de 0 bytes? Nos olvidamos de una imagen rota, la petición se hace al otro subdominio, y los móviles..., los móviles, ¿qué van a sufrir con un archivo de 0 bytes? Si al final lo importante es llamar al servidor y que responda con una cookie HTTP o acepte la que se le envíe.

Que ya digo que no creo en absoluto que arregle lo mío, pero nos olvidamos totalmente de escabrosos engorros con imágenes. Que si se ven rotas, que si tal y lo cual.

Lo de machacarla, ahí ya no tengo idea, pero si existe, no la reescribas o intentes reescribir.


melado escribió:¿Por qué una cabecera Link en la respuesta HTTP? Para intentar que la petición se haga lo antes posible.


Sí, ya, otra página diferente de W3 había leído (https://w3c.github.io/preload/), pero fíjate tú, que ellos también te ponen un archivo CSS como ejemplo.

melado escribió:¿Por qué código JS si solo hay una imagen? Para reintentarlo pasado un tiempo en caso de fallar la petición (paquetes perdidos, error momentáneo del servidor...).
[...]

Ah. No hay ningún service worker en todo este sistema, no sé dónde has visto uno. El único que tenemos se usa para las notificaciones push.


Tienes razón, por su comportamiento, confundí el script con un worker. Derrape.


melado escribió:Mi consejo para cualquiera que tenga alergia a este sistema es que bloquee las peticiones que empiezan por /rpc.php?m=isb en su bloqueador favorito, con el cual estoy seguro que ya cuentan. Resolverá todos los problemas y, si no se visita esports, no causará ninguno nuevo.


No puedo, pero vaya, el que quiera, ya sabe.


En fin. Ya siento venir como dando lecciones, porque no soy quién, ni mucho menos tengo tus conocimientos, pero paso, tal vez, demasiado tiempo aquí y cuando veo algo raro [para mí]... :-|
JohnH escribió:Si yo sé que me meto donde no me llaman, pero..., digo yo, no sé, ¿por qué no poner el Host de la cookie a .elotrolado.net y nos olvidamos de historias raras, que para eso es posible con un simple puntito .?

Porque en este dominio hay más gente que nosotros, no sabemos cuál más habrá en el futuro, y no queremos andar regalando las cookies del login por todo el dominio indiscriminadamente. Se valoró como última opción si este invento no funcionaba, pero funcionó :)

Que está puesta para los Google Ads, no sé por qué no para esto

Eso no es cierto. Están puestas las suyas propias, no las nuestras del login, que son las que son importantes por seguridad.

¿por qué no tirar por la tangente y en vez de pedir una imagen, pedimos un archivo CSS de 0 bytes?

En mis pruebas con Chrome la imagen + el código JS de fallback fue el método más robusto. Los CSS se solicitaban más tarde o directamente no se hacían en algunas ocasiones, como en redirecciones. Tampoco cambiaría demasiado, serían 26 bytes menos cada 30 minutos de navegación, que es cuando se actualizan las cookies si mal no recuerdo. La frase anterior son 140 bytes.

De todas formas no acabo de entender cuál es el problema que tienes. ¿Se te ve una imagen rota en alguna parte? ¿O qué?
melado escribió:De todas formas no acabo de entender cuál es el problema que tienes. ¿Se te ve una imagen rota en alguna parte? ¿O qué?


Problema tampoco. La frustración de que ver que, cuando le da hipo al navegador, cuando se envía la cabecera Link, la página carga temporalmente sin CSS. Si usas un navegador Gecko (no sé si en el nuevo motor de Mozilla seguirá vigente), cambia la preferencia permissions.default.stylesheet de tipo entero a 2 y entenderás cómo se carga la web.

Que es un segundo, hasta que se carga el CSS, pero "me he vuelto loco" [qmparto] durante este tiempo intentando saber qué era lo que pasaba porque yo también toco mis cosas, no por esta web en particular, y pensaba que la había cagado con alguna configuración. Y no había manera de dar con la tecla.

Problema..., problema, ninguno, porque el problema es mío (no lo he conseguido replicar, así que es cosa mía/bug), pero era por contarlo y saber qué pasaba. Y, ¡qué coño!, quejarme de los esports :P Porque todo esto parte de los esports :-|

Los argumentos de la causa ya los he visto y toca ajo y agua y ya está :)

De las cookies, se supone que el dominio es todo vuestro :-? M'as'matao. No adivino quién usa otra sección.

Las de Google Ads me refiero a esto, aunque es meterse en otras harinas y lo comentaba en relación a lo que hacías para que el login estuviera en diferentes subdominios, pero si no se puede, pues no se puede, ya está ;):
Imagen

https://policies.google.com/technologies/types
Sometimes advertising cookies may be set on the domain of the site you're visiting. In the case of advertising we serve across the web, cookies named ‘__gads’ or ‘__gac’ may be set on the domain of the site you're visiting. Unlike cookies that are set on Google's own domains, these cookies can't be read by Google when you're on a site other than the one on which they were set. They serve purposes such as measuring interactions with the ads on that domain and preventing the same ads from being shown to you too many times.
JohnH escribió:Problema tampoco. La frustración de que ver que, cuando le da hipo al navegador, cuando se envía la cabecera Link, la página carga temporalmente sin CSS. Si usas un navegador Gecko (no sé si en el nuevo motor de Mozilla seguirá vigente), cambia la preferencia permissions.default.stylesheet de tipo entero a 2 y entenderás cómo se carga la web.

No he podido reproducir eso en el último ESR de Firefox. Si estás en una versión anterior... ya sabes. De todas formas es algo que debería ocurrir como mucho cada ¿30 minutos?, así que no es tampoco una desgracia.

De las cookies, se supone que el dominio es todo vuestro :-? M'as'matao. No adivino quién usa otra sección.

[angelito]

Haber hay (como pista puedes ver el SAN del certificado...), aunque en el pasado ha habido más, y definitivamente no podemos predecir el futuro. Es un caso similar al de GitHub cuando cambió el dominio de los usuarios a github.io: https://blog.github.com/2013-04-05-new- ... github-io/

Las de Google Ads me refiero a esto (...)

Sí, te había entendido. Google solo sirve unos identificadores y los puede esparcir por todo el dominio si quieren sin problemas. Las cookies de EOL que llevan información del login son un asunto distinto y no me gustaría que salieran de www.
6 respuestas