cURL

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda
cURL
http://curl.haxx.se
Curl-logo.svg
Screenshot of cURL command line interface.png

cURL en zsh
Información general
Desarrollador(es) Daniel Stenberg
Lanzamiento inicial abril de 1997
Última versión estable 7.61.1 (info)
5 de septiembre de 2018 (3 días)
Género Cliente de descarga, Cliente FTP, Cliente HTTP
Programado en C
Sistema operativo Multiplataforma
Licencia Derivada de MIT
Idiomas inglés
En español No

cURL (/kə:(r)l/.[2]​) es un proyecto de software consistente en una biblioteca (libcurl) y un intérprete de comandos (curl) orientado a la transferencia de archivos. Soporta los protocolos FTP, FTPS, HTTP, HTTPS, TFTP, SCP, SFTP, Telnet, DICT, FILE y LDAP, entre otros. La primera versión se publicó en 1997 y se basó en una pequeña herramienta llamada httpget escrita por el brasileño Rafael Sagula.[3]

cURL soporta certificados HTTPS, HTTP POST, HTTP PUT, subidas FTP, Kerberos, subidas mediante formulario HTTP, proxies, cookies, autenticación mediante usuario y contraseña (Basic, DIgest, NTLM y Negotiate para HTTP y kerberos 4 para FTP), continuación de transferencia de archivos, tunneling de proxy HTTP y otras prestaciones. cURL es Open Source, software libre distribuido bajo la Licencia MIT.

El principal propósito y uso para cURL es automatizar transferencias de archivos o secuencias de operaciones no supervisadas. Es por ejemplo, una herramienta válida para simular las acciones de usuarios en un navegador web.

Historia[editar]

Creada en 1997 y con capacidad añadida de manejar FTP en 1998, su desarrollador Daniel Stenberg, decide cambiar el nombre de la aplicación a cURL.[4]​ Dicho cambio de nombre se debió en parte a que su nombre anterior era urlget y no concordaba con la gramática inglesa así que se decidió por dejar solo URL y agregarle el prefijo c que se pronuncia como el verbo see (ver) en inglés, así que se pronunciaría como "ver URL", traducido al idioma castellano. Tiempo después se propuso que cURL significara, en un acrónimo recursivo, Curl URL Request Library, lo cual consideraron sencillamente genial.

En la actualidad se calcula que existen un millardo de usuarios de cURL.[5]​ Dicha cifra atisba de no descender ya que mientras se mantengan las tranferencias de datos orientados a archivos en la séptima capa del modelo OSI, cURL siempre estará allí en código fuente abierto para ser adaptado a las futuras necesidades de los usuarios y la programación.

LibcURL[editar]

LibcURL es la biblioteca/API correspondiente que los usuarios pueden incorporar en sus programas donde cURL actúa como un envoltorio (wrapper) aislado para la biblioteca LibcURL.[6]​ LibcURL se usa para proveer capacidades de transferencia de URL a numerosas aplicaciones, tanto libres y open source como privativas. La biblioteca "libcurl" puede ser usada desde más de 30 lenguajes distintos.

El 23 de marzo de 2013 Daniel Stenberg publicó en su blog las razones por las cuales durante mucho tiempo CURL permanecerá en la versión 7.X .[7]​ La razón práctica para ello es que cambiar el número de versión a 8 ocasionará mucho más trabajo a los demás programadores que dependen de esta librería quienes a su vez tienen otros programadores que también deberán compilar de nuevo sus programas. Aunque Stenberg hace un atisbo en su blog de este efecto, se puede inferir que ocasiona un efecto cascada (no confundir con Desarrollo en cascada) en muchísimos servidores alrededor del mundo. Esto se debe al paradigma de Interfaz binaria de aplicaciones, abreviado como ABI, y que depende del número de versión, el cual es llamado también número ABI. Al acanzar CURL la versión 7.60 el autor de nuevo hace mención al tema porque según sus cálculos estadísticos a la velocidad de avance y liberación de versiones pasarán al menos 6 años en alcanzar la versión 7.99 la cual no deberán sobrepasar, mucho antes de ello ha de cambiar a la versión ocho. Si por ejemplo se liberara la versión 7.100 pudiera haber confusiones en los programadores que utilizan esta librería con la versión 7.10 y esto es debido a que los "números" de versiones son evaluados como cadenas de texto, caracteres alfanuméricos.[8]

A pesar de que el asunto reviste total seriedad, este artículo ocasionó confusión entre la comunidad de desarrollo y Stenberg hubo de realizar un par de aclaratorias al final de la entrada: explica que es una información importante que va implícita en el código fuente no obstante hace él hace la declaración pública a fin de prevenir malentendidos (de hecho en el artículo se ofrece una breve guía de trabajo dirigida exclusivamente a los desarrolladores) y que de ninguna manera la velocidad de mantenimiento y desarrollo de la librería disminuye ni se ve afectada por ello.[9]

Referencias[editar]

  1. cURL History Page
  2. cURL - Frequently Asked Questions
  3. Stenberg, Daniel (30 de septiembre de 2015). «Everything curl» (pdf). Gitbook (en inglés). Archivado desde el original el 14 de abril de 2017. Consultado el 16 de enero de 2018. «A quick look-around at the time had Daniel find a tiny tool named httpget (written by a Brazilian named Rafael Sagula). It did the job, almost, just needed a few little a tweaks here and there and soon Daniel had taken over maintenance of the few hundred lines of code it was.» 
  4. Stenberg, Daniel (20 de marzo de 2015). «curl, 17 years old today» (en inglés). Archivado desde el original el 20 de marzo de 2015. Consultado el 27 de enero de 2018. «The tool we had been working on for a while was still called urlget in the beginning of 1998 but as we just recently added FTP upload capabilities that name turned wrong and I decided cURL would be more suitable.» 
  5. Stenberg, Daniel (20 de marzo de 2015). «curl, 17 years old today» (en inglés). Archivado desde el original el 20 de marzo de 2015. Consultado el 27 de enero de 2018. «Rough estimates say we may have a billion users already. Chances are, if things don’t change too drastically without us being able to keep up, that we will have even more in the future.» 
  6. «PHP y cURL». KS7000 +WP. 31 de mayo de 2017. Archivado desde el original el 17 de enero de 2018. Consultado el 16 de enero de 2018. «El software de enlace (librerías) de curl para PHP fue uno, cuidado sino, el primero de los enlaces que realmente captura y lo usa ampliamente. Rápidamente fue adoptado como una manera por defecto para transferir datos y se ha mantenido en esa posición por más de una década». 
  7. Stenberg, Daniel (23 de marzo de 2018). «Why no curl 8» (html). daniel.haxx.se (en inglés). Archivado desde el original el 29 de marzo de 2013. Consultado el 19 de mayo de 2018. «Changing the number has a ripple effect so that at some point in time a new version has to replace all the old ones and applications need to be rebuilt – and at worst also possibly have to be rewritten in parts to handle the ABI/API changes. The amount of work done “out there” on hundreds or thousands of applications for a single little libcurl tweak can be enormous. The last time we bumped the ABI, we got a serious amount of harsh words and critical feedback and since then we’ve gotten many more users!» 
  8. Stenberg, Daniel (16 de mayo de 2018). «The curl 7 series reaches 60» (html). daniel.haxx.se (en inglés). Archivado desde el original el 16 de mayo de 2018. Consultado el 19 de mayo de 2018. «I believe we shouldn't allow the minor number to go above 99 (because I think it will cause serious confusion among users) so we should come up with a scheme to switch to version 8 before 7.99.0 gets old. If we keeping doing a new minor version every eight weeks, which seems like the fastest route, math tells us that's a mere 6 years away.» 
  9. Stenberg, Daniel (23 de marzo de 2018). «Why no curl 8» (html). daniel.haxx.se (en inglés). Archivado desde el original el 29 de marzo de 2013. Consultado el 19 de mayo de 2018. «Update April 6th: this article has been read by many and I’ve read a lot of comments and some misunderstandings about it. Here’s some additional clarifications: 1. this isn’t stuff we’ve suddenly realized now. This is truths and facts we’ve learned over a long time and this post just makes it more widely available and easier to find. We already worked with this knowledge. I decided to blog about it since it struck me we didn’t have it documented anywhere. 2. not doing version 8 (in a long time) does not mean we’re done or that the pace of development slows down. We keep doing releases bimonthly and we keep doing an average of 30 something bugfixes in each release.»