ob_start - remove html tags php

¿Por qué utilizar el buffer de salida en PHP? (11)

He leído bastante material en Internet en el que diferentes autores sugieren utilizar el buffer de salida. Lo curioso es que la mayoría de los autores defienden su uso solo porque permite mezclar los encabezados de respuesta con el contenido real. Francamente, creo que las aplicaciones web responsables no deben mezclar encabezados de salida y contenido, y los desarrolladores web deben buscar posibles fallas lógicas en sus scripts que resultan en el envío de encabezados después de que se haya generado la salida. Este es mi primer argumento en contra de la API de buffer de salida ob_* . Incluso por la poca comodidad que tiene (mezclar encabezados con resultados) no es motivo suficiente para usarlo, a menos que sea necesario modificar scripts rápidamente, que generalmente no es el objetivo ni el camino en una aplicación web seria.

Además, creo que la mayoría de las personas que trabajan con la API de almacenamiento en búfer de salida no piensan en el hecho de que, incluso sin el almacenamiento de salida explícito habilitado, PHP en combinación con el servidor web en el que está conectado, todavía realiza un almacenamiento intermedio interno de todos modos. Es fácil de verificar: haz un eco de una cuerda corta, duerme por digamos 10 segundos y haz otro eco. Solicite su secuencia de comandos con un navegador y observe la pausa de la página en blanco durante 10 segundos, y ambas líneas aparecerán a continuación. Antes de que algunos digan que es un artefacto de representación, no tráfico, el seguimiento del tráfico real entre el cliente y el servidor muestra que el servidor ha generado el encabezado Content-Length con un valor apropiado para todo el resultado, sugiriendo que el resultado no fue enviado progresivamente con cada llamada de echo , pero se acumuló en algún buffer y luego se envió en la terminación del script. Esta es una de mis quejas con el almacenamiento en búfer de salida explícito, ¿por qué necesitamos dos implementaciones de buffer de salida diferentes una encima de la otra? ¿Puede ser porque el almacenamiento en búfer interno (inaccesible) del servidor PHP / Web está sujeto a condiciones que un desarrollador de PHP no puede controlar y, por lo tanto, no es realmente utilizable?

En cualquier caso, por mi parte, empiezo a pensar que se debe evitar el almacenamiento en búfer explícito de salida (la serie de funciones ob_* ) y confiar en el implícito, ayudándolo con la función de buena flush , cuando sea necesario. Tal vez si el servidor web tuviera alguna garantía para enviar efectivamente la salida al cliente con cada llamada de eco / impresión, entonces sería útil configurar el almacenamiento en memoria caché explícito; después de todo, no se quiere enviar una respuesta al cliente con unos 100 pedazos de bytes. Pero la alternativa con dos amortiguadores parece una capa de abstracción algo inútil.

Entonces, en última instancia, ¿las aplicaciones web serias necesitan buffer de salida?

Sí

Las aplicaciones web serias necesitan buffer de salida en una situación específica:

Su aplicación quiere control sobre lo que es generado por un código de terceros , pero no hay API para controlar lo que ese código emite.
En ese escenario, puede llamar a ob_start() justo antes de darle control a ese código, perder el tiempo con lo que está escrito (idealmente con la devolución de llamada, o examinando el contenido del buffer si es necesario), y luego llamar a ob_flush() .

En última instancia, las funciones ob_ de PHP son un mecanismo para capturar lo que otro bit de código hace en un búfer con el que puede meterse .

Si no necesita inspeccionar o modificar lo que está escrito en el búfer, no se gana nada al usar ob_start() .

Muy probablemente, su "aplicación seria" es de hecho un marco de algún tipo.

Ya tiene buffer de salida, de todos modos

No necesita ob_start() para utilizar el almacenamiento en búfer de salida. Su servidor web ya almacena en búfer su salida.

El uso de ob_start() no le proporciona un mejor almacenamiento en búfer de salida; de hecho, podría aumentar el uso de la memoria y la latencia de la aplicación al "acumular" datos que el servidor web ya habría enviado al cliente.

Tal vez `ob_start()` ...

... para mayor comodidad cuando se enjuaga

En algunos casos, es posible que desee controlar cuándo el servidor web vacía su búfer, según algunos criterios que su aplicación conoce mejor. La mayoría de las veces, sabes que acabas de escribir una ''unidad'' lógica que el cliente puede usar, y le estás diciendo al servidor web que se descargue ahora y no espere a que se llene el búfer de salida. Para hacer esto, simplemente es necesario emitir su salida de forma normal y acentuarla con flush() .

Más raramente, querrá retener datos del servidor web hasta que tenga suficientes datos para enviar. No tiene sentido interrumpir al cliente con la mitad de las noticias, especialmente si el resto de las noticias tomará algún tiempo para estar disponible. Un simple ob_start más tarde concluido por un ob_end_flush() puede ser lo más simple y apropiado para hacer.

... si tienes la responsabilidad de ciertos encabezados

Si su aplicación asume la responsabilidad de calcular los encabezados, lo cual solo se puede determinar después de que esté disponible la respuesta completa, entonces puede ser aceptable.

Sin embargo, incluso aquí, si no puedes hacer nada mejor que derivar el encabezado inspeccionando el búfer de salida completo, también puedes dejar que el servidor web lo haga (si es necesario). El código del servidor web está escrito, probado y compilado; es poco probable que lo mejore.

Por ejemplo, solo sería útil establecer el encabezado Content-Length si su aplicación conoce la longitud del cuerpo de respuesta antes de que compute el cuerpo de la respuesta.

No hay panacea para malas prácticas

No debe ob_start() para evitar las disciplinas de:

abrir , usar y cerrar rápidamente recursos como memoria, hilos y conexiones de bases de datos
emitiendo encabezados primero, y el cuerpo segundo
haciendo todos los cálculos y manejo de errores que pueda, antes de comenzar la respuesta

Si haces esto, te causarán una deuda técnica que te hará llorar algún día.

Bien, aquí está la verdadera razón: la salida no se inicia hasta que todo está hecho. Imagine una aplicación que abre una conexión SQL y no la cierra antes de iniciar la salida. Lo que sucede es que el script obtiene una conexión, comienza a emitir, espera que el cliente obtenga todo lo que necesita y, al final, cierra la conexión. Woot, una conexión de 2s donde un 0.3s uno sería suficiente.

Ahora, si almacena en búfer, su secuencia de comandos se conecta, coloca todo en un búfer, se desconecta automáticamente al final y luego comienza a enviar el contenido generado al cliente.

El almacenamiento en búfer de salida es crítico en IIS, que no tiene búfer interno propio. Con el almacenamiento en búfer de salida desactivado, los scripts PHP parecen ejecutarse mucho más lentamente que en Apache. Enciéndalo y corren muchas veces más rápido.

Es útil si intenta mostrar una barra de progreso durante una página que lleva algún tiempo procesar. Como el código PHP no tiene múltiples subprocesos, no puede hacer esto si el proceso se cuelga haciendo 1 función.

Es una vieja pregunta, pero nadie dijo que una característica importante del almacenamiento en memoria es filtrar . Es posible preprocesar el búfer antes de enviarlo al cliente.

Este es un concepto muy poderoso y abre muchas posibilidades intrigantes. En un proyecto usé dos filtros simultáneamente:

traducción ad-hoc de términos (reemplazo de textos cortos)
ofuscación de HTML, CSS y Javascript (no me preguntes por qué)

Para habilitar el filtrado de salida, llame a ob_start("callback") donde la callback es el nombre de la función de filtrado. Para más detalles, consulte el manual de PHP para ob_start : http://php.net/manual/en/function.ob-start.php

Los casos de uso más obvios son:

Un filtro de salida (por ejemplo, ob_gzhandler o cualquier cantidad de filtros que pueda diseñar por su cuenta); He hecho esto con API que solo admiten salida (en lugar de devolver valores) donde quería hacer un análisis posterior con una biblioteca como phpQuery .
Mantenimiento (en lugar de reescritura) del código escrito con todos los problemas que analiza; esto incluye cosas como el envío de encabezados después de que comenzó la producción (crédito Don Dickinson) o la supresión de ciertos resultados que ya se han generado.
Producción escalonada (crédito aquí para Tom y Langdon); tenga en cuenta que sus pruebas pueden haber fallado porque entra en conflicto con el búfer interno predeterminado de PHP / Apache, pero es posible hacerlo, simplemente requiere que se vacíe una cierta cantidad antes de que PHP envíe algo, aunque PHP aún mantendrá la conexión abierta.

Si desea enviar un informe a la pantalla pero también enviarlo por correo electrónico, el almacenamiento en búfer de salida le permite no tener que repetir el procesamiento para generar dos veces su informe.

Solíamos usarlo en el día para páginas con tablas enormemente largas llenas de datos de una base de datos. Vaciaría el buffer cada x filas para que el usuario supiera que la página realmente funcionaba. Luego, alguien escuchó acerca de la usabilidad y páginas como esa obtuvieron paginación y búsqueda.

Utilice el almacenamiento en búfer de salida para almacenar en caché los datos en un archivo, para otras solicitudes similares si realiza muchas transacciones y procesos de bases de datos.

Utilizo buffering de salida para evitar generar HTML por concatenación de cadenas, cuando necesito saber el resultado de una operación de renderización para crear algún resultado antes de usar el renderizado.

Utilizo el búfer de salida por una razón ... me permite enviar un encabezado de "ubicación" después de que comencé a procesar la solicitud.