Pautas y mejores prácticas para hacer un sitio amigable al proxy

Esta es una pregunta para los desarrolladores de proxy y plugins.

La mentalidad habitual cuando se trata de sitios específicos es “Hacen cambios que rompen nuestro complemento; cambiamos la lógica para que funcione de nuevo” .

Pero, ¿y si al otro lado también le preocupa esto? Si queremos comstackr un conjunto de pautas y mejores prácticas para el desarrollo de sitios para un sitio compatible con el proxy, ¿qué sugiere que debería incluirlo? Piensa en las tuercas difíciles que has tenido que romper. ¿Recuerda esos momentos que deseaba que el desarrollador del sitio hubiera hecho una característica diferente de manera diferente? ¿Cómo?

Dado que esto tiene que ver con la encoding, no creo que deba ir a Serverfault.

Edit: Después de leer el comentario de Pekka, creo que debería agregar más información de fondo.

Hay scripts de proxy web por ahí, como glype y PHProxy. Como la secuencia de comandos debe hacer frente a muchas condiciones desconocidas, no sirve para muchos sitios. Debido a que la cantidad de tales sitios es abrumadora, no tiene sentido tratar de hacer que la lógica interna del proxy sea lo suficientemente sofisticada para manejar esta gran variedad. Aquí es donde los complementos son útiles. El script principal o base implementa un mecanismo para invocar código de complemento en una base por sitio.

Entonces, si el proxy no sirve, digamos facebook.com, que es el caso, por cierto, un progtwigdor interesado en el desafío investiga y depura, para encontrar dónde y por qué se rompe la cadena y qué se debe hacer para resolver la cuestión. El codificador implementa su corrección como un complemento para ese sitio en particular y los usuarios podrían colocar el complemento en su directorio de complementos.

Pero también sucede que algo cambia en el sitio, y ese cambio hace que el complemento vuelva a fallar. Por lo tanto, es una coincidencia constante para ponerse al día con los cambios más recientes de un sitio. La ironía de la situación es que muchos desarrolladores de sitios no saben, ni se preocupan por el impacto que sus decisiones de diseño puedan tener en la capacidad de proxy del contenido. Pero algunos sitios tienen buenas razones para preocuparse por la capacidad de los visitantes para acceder a su contenido a través de proxies. No quiero meterme en política aquí, así que lo dejo a usted para adivinar por qué esto puede ser importante para algunos sitios.

Esta pregunta es un bash de aprovechar el conocimiento colectivo y la experiencia de los autores de proxy y complementos para crear un conjunto de pautas para hacer que un sitio sea compatible con el proxy.

No etiqueté la pregunta php originalmente, ya que se refiere principalmente a la salida de un sitio, no a cómo se genera. Pero decidió etiquetarlo así, porque mejorará la visibilidad de la pregunta y la etiqueta también podría justificarse en función del público objective. También estoy creando esta wiki de la comunidad, así que si sientes que la etiqueta php debería ser eliminada, simplemente hazlo.

Esta es una pregunta interesante y no creo que haya una buena solución general. Básicamente, usted quiere que el contenido de su sitio sea transformable por un tercero sobre el cual no tiene control y posiblemente no tenga conocimiento de las transformaciones.

La forma tradicional en que se resuelve este problema es tener una API publicada que permite a terceros consultar los datos que desean de una manera controlada que no se basa en el raspado de la pantalla. La API a menudo solo expondrá un subconjunto de la funcionalidad, generalmente porque el sitio requiere que los usuarios visualicen páginas para generar ingresos por publicidad (o algún otro tipo de ingreso).

Podría generar páginas muy simples, en efecto utilizando una API HTML, y usar Javascript y CSS para hacer que las páginas sean más fáciles de usar. Sin embargo, esto podría no ser apropiado para la mayoría de los sitios. Sin embargo, el enfoque de “mejora progresiva” proclamado por jQuery y otros es similar: sirve contenido básico, semántico y agrega funcionalidad y dinamismo a través de JS y CSS.

Podría usar microformatos para hacer que cierto contenido de la página sea más accesible. Debe usar HTML semántico y poner muchas clases e identificaciones en los elementos de la página para que los autores de los complementos puedan encontrar el contenido relevante que necesitan.

Me sorprende que, sin importar lo que necesiten estos proxies, aprendan a analizar sus páginas al menos una vez. Podría documentar el proceso (tal vez lanzar uno o dos complementos).

No creo que pueda evitar obligar a los autores de complementos a volver a codificar cuando lance nuevas versiones de su sitio. Podría establecer una política de tener un período beta, donde tanto las versiones antiguas como las nuevas del sitio estén disponibles, y esto le daría a los autores de complementos la oportunidad de actualizar sus complementos sin interrupciones en el servicio para sus usuarios.

No estoy seguro de si esto le preocupa o no, pero en la actualidad solo recuerdo dos cosas que se deben tener en cuenta al trabajar en un sitio compatible con el proxy. Uno es el encabezado que puede afectar a los sitios visitados detrás del proxy y el otro es la detección de IP. El encabezado de control de caché (público / privado) y otro encabezado pueden afectar la velocidad y la privacidad del usuario. IP detectada puede de proxy y no de usuario. Por lo tanto, estas cosas deben tenerse en cuenta.