[catagits/fcgi2.git] / doc / www5-api-workshop.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">\r
<HTML>\r
   <HEAD>\r
      <TITLE>\r
         FastCGI: A High-Performance Gateway Interface\r
      </TITLE>\r
<STYLE TYPE="text/css">\r
 h5.c2 {text-align: center}\r
 div.c1 {text-align: center}\r
</STYLE>\r
   </HEAD>\r
   <BODY>\r
      <DIV CLASS="c1">\r
         <H2>\r
            FastCGI: A High-Performance Gateway Interface\r
         </H2>\r
         Position paper for the workshop &quot;Programming the Web - a search for APIs&quot;,<BR>\r
         Fifth International World Wide Web Conference, 6 May 1996, Paris, France.<BR>\r
         <P>\r
            Mark R. Brown<BR>\r
            Open Market, Inc.<BR>\r
         </P>\r
         <P>\r
            2 May 1996<BR>\r
         </P>\r
      </DIV>\r
      <P>\r
      </P>\r
      <H5 CLASS="c2">\r
         Copyright &copy; 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.<BR>\r
         Tel: 617-621-9500 Fax: 617-621-1703 URL: <A HREF=\r
         "http://www.openmarket.com/">http://www.openmarket.com/</A><BR>\r
      </H5>\r
      <HR>\r
      <H3>\r
         Abstract\r
      </H3>\r
      <P>\r
         FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI\r
         without introducing any of the new problems associated with writing applications to lower-level Web server\r
         APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key\r
         considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including\r
         applications written in popular scripting languages such as Perl), supporting both single-threaded and\r
         multi-threaded application programming, supporting distributed configurations for scaling and high\r
         availability, and generalizing the roles that gateway applications can play beyond CGI&#39;s\r
         &quot;responder&quot; role.\r
      </P>\r
      <P>\r
         For more information on FastCGI, including an interface specification and a module for the Apache server,\r
         visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
      </P>\r
      <H3>\r
         1. Introduction\r
      </H3>\r
      <P>\r
         The surge in the use of the Web by business has created great demand for applications that create dynamic\r
         content. These applications allow businesses to deliver products, services, and messages whose shape and\r
         content are influenced by interaction with and knowledge of users.\r
      </P>\r
      <P>\r
         This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway\r
         Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not\r
         all) of the performance problems with CGI, but are not designed to meet the need of business applications.\r
         When applied to business applications, Web server APIs suffer from these problems:\r
      </P>\r
      <UL>\r
         <LI>\r
            <B>Complexity.</B> Server APIs introduce a steep learning curve, with increased implementation and\r
            maintenance costs.\r
         </LI>\r
         <LI>\r
            <B>Language dependence.</B> Applications have to be written in a language supported by the server API\r
            (usually C/C++). Perl, the most popular language for CGI programs, can&#39;t be used with any existing\r
            server API.\r
         </LI>\r
         <LI>\r
            <B>No process isolation.</B> Since the applications run in the server&#39;s address space, buggy\r
            applications can corrupt the core server (or each other). A malicious or buggy application can compromise\r
            server security, and bugs in the core server can corrupt applications.\r
         </LI>\r
         <LI>\r
            <B>Proprietary.</B> Coding your application to a particular API locks you into a particular server.\r
         </LI>\r
         <LI>\r
            <B>Tie-in to server architecture.</B> API applications have to share the same architecture as the server:\r
            If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has\r
            single-threaded processes, multi-threaded applications don&#39;t gain any performance advantage. Also, when\r
            the server&#39;s architecture changes, the API will usually have to change, and applications will have to\r
            be adapted or rewritten.\r
         </LI>\r
      </UL>\r
      <P>\r
         Web server APIs are suitable for applications that require an intimate connection to the core Web server, such\r
         as security protocols. But using a Web server API for a Web business application would be much like using an\r
         old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business\r
         transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost\r
         penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior\r
         performance to boot. Nobody uses the old technology unless they are already locked into it.\r
      </P>\r
      <P>\r
         FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI&#39;s performance problems.\r
         The major implementation differences are:\r
      </P>\r
      <UL>\r
         <LI>\r
            FastCGI processes are persistent: after finishing a request, they wait for a new request instead of\r
            exiting.\r
         </LI>\r
         <LI>\r
            Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the\r
            environment information, standard input, output, and error over a single full-duplex connection. This\r
            allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the\r
            FastCGI application.\r
         </LI>\r
      </UL>\r
      <P>\r
         FastCGI communicates the exact same information as CGI in a different way. Because FastCGI <I>is</I> CGI, and\r
         like CGI runs applications in separate processes, it suffers none of the server API problems listed above.\r
      </P>\r
      <H3>\r
         2. Migration from CGI\r
      </H3>\r
      <P>\r
         Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the\r
         protocol details from the developer. This library, which is freely available, makes writing FastCGI programs\r
         as easy as writing CGI applications.\r
      </P>\r
      <P>\r
         The application library provides replacements for the C language standard I/O (stdio) routines such as\r
         <TT>printf()</TT> and <TT>gets()</TT>. The library converts references to environment variables, standard\r
         input, standard output, and standard error to the FastCGI protocol. References to other files &quot;fall\r
         through&quot; to the underlying operating system standard I/O routines. This approach has several benefits:\r
      </P>\r
      <UL>\r
         <LI>\r
            Developers don&#39;t have to learn a new API to develop FastCGI applications.\r
         </LI>\r
         <LI>\r
            Existing CGI programs can be migrated with minimal source changes.\r
         </LI>\r
         <LI>\r
            FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the\r
            interpreter source code.\r
         </LI>\r
      </UL>\r
      <P>\r
         Here&#39;s a simple FastCGI application:\r
      </P>\r
      <BR>\r
      <BR>\r
<PRE>\r
    #include &lt;fcgi_stdio.h&gt;\r
\r
    void main(void)\r
    {\r
        int count = 0;\r
        while(FCGI_Accept() &gt;= 0) {\r
            printf(&quot;Content-type: text/html\r\n&quot;);\r
            printf(&quot;\r\n&quot;);\r
            printf(&quot;Hello world!&lt;br&gt;\r\n&quot;);\r
            printf(&quot;Request number %d.&quot;, count++);\r
        }\r
        exit(0);\r
    }\r
</PRE>\r
      <P>\r
         This application returns a &quot;Hello world&quot; HTML response to the client. It also keeps a counter of the\r
         number of times it has been accessed, displaying the value of the counter at each request. The\r
         <TT>fcgi_stdio.h</TT> header file provides the FastCGI replacement routines for the C standard I/O library.\r
         The <TT>FCGI_Accept()</TT> routine accepts a new request from the Web server.\r
      </P>\r
      <P>\r
         The application library was designed to make migration of existing CGI programs as simple as possible. Many\r
         applications can be converted by adding a loop around the main request processing code and recompiling with\r
         the FastCGI application library. To ease migration to FastCGI, executables built with the application library\r
         can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the\r
         execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.\r
      </P>\r
      <P>\r
         Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language\r
         interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix\r
         platforms are available from the <I>www.fastcgi.com</I> Web site. The interpreters are backward-compatible:\r
         They can run standard Tcl and Perl applications.\r
      </P>\r
      <H3>\r
         3. Single-threaded and multi-threaded applications\r
      </H3>\r
      <P>\r
         FastCGI gives developers a free choice of whether to develop applications in a single-threaded or\r
         multi-threaded style. The FastCGI interface supports multi-threading in two ways:\r
      </P>\r
      <UL>\r
         <LI>\r
            Applications can accept concurrent Web server connections to provide concurrent requests to multiple\r
            application threads.\r
         </LI>\r
         <LI>\r
            Applications can accept multiplexed Web server connections, in which concurrent requests are communicated\r
            over a single connection to multiple application threads.\r
         </LI>\r
      </UL>\r
      <P>\r
         Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- so many\r
         developers will prefer to program in the familiar single-threaded style. By having several concurrent\r
         processes running the same application it is often possible to achieve high performance with single-threaded\r
         programming.\r
      </P>\r
      <P>\r
         The FastCGI interface allows Web servers to implement <I>session affinity</I>, a feature that allows\r
         applications to maintain caches of user-related data. With session affinity, when several concurrent processes\r
         are running the same application, the Web server routes all requests from a particular user to the same\r
         application process. Web server APIs don&#39;t provide this functionality to single-threaded applications, so\r
         the performance of an API-based application is often inferior to the performance of the corresponding FastCGI\r
         application.\r
      </P>\r
      <H3>\r
         4. Distributed FastCGI\r
      </H3>\r
      <P>\r
         Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run\r
         remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to\r
         systems that don&#39;t have Web servers.\r
      </P>\r
      <P>\r
         Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can\r
         communicate through the firewall to internal databases. For instance, an application might need to\r
         authenticate incoming users as customers in order to give access to certain documents on the external Web\r
         site. With FastCGI this authentication can be done without replicating data and without compromising security.\r
      </P>\r
      <H3>\r
         5. Roles\r
      </H3>\r
      <P>\r
         A problem with CGI is its limited functionality: CGI programs can only provide responses to requests. FastCGI\r
         provides expanded functionality with support for three different application &quot;roles&quot;:\r
      </P>\r
      <UL>\r
         <LI>\r
            <B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by\r
            CGI today.\r
         </LI>\r
         <LI>\r
            <B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the\r
            client.\r
         </LI>\r
         <LI>\r
            <B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as\r
            performing a username/password database lookup).\r
         </LI>\r
      </UL>\r
      <P>\r
         Other roles will be defined in the future. For instance, a &quot;logger&quot; role would be useful, where the\r
         FastCGI program would receive the server&#39;s log entries for real-time processing and analysis.\r
      </P>\r
      <H3>\r
         6. Conclusions\r
      </H3>\r
      <P>\r
         Today&#39;s Web business applications need a platform that&#39;s fast, open, maintainable, straightforward,\r
         stable, and secure. FastCGI&#39;s design meets these requirements, and provides a logical migration path from\r
         the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI&#39;s\r
         benefits without losing their existing investment in CGI applications.\r
      </P>\r
      <P>\r
         For more information about FastCGI, visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
      </P>\r
   </BODY>\r
</HTML>\r
\r
Commit	Line	Data
e88ae2ce	1	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">\r
	2	<HTML>\r
	3	<HEAD>\r
	4	<TITLE>\r
	5	FastCGI: A High-Performance Gateway Interface\r
	6	</TITLE>\r
	7	<STYLE TYPE="text/css">\r
	8	h5.c2 {text-align: center}\r
	9	div.c1 {text-align: center}\r
	10	</STYLE>\r
	11	</HEAD>\r
	12	<BODY>\r
	13	<DIV CLASS="c1">\r
	14	<H2>\r
	15	FastCGI: A High-Performance Gateway Interface\r
	16	</H2>\r
	17	Position paper for the workshop "Programming the Web - a search for APIs",<BR>\r
	18	Fifth International World Wide Web Conference, 6 May 1996, Paris, France.<BR>\r
	19	<P>\r
	20	Mark R. Brown<BR>\r
	21	Open Market, Inc.<BR>\r
	22	</P>\r
	23	<P>\r
	24	2 May 1996<BR>\r
	25	</P>\r
	26	</DIV>\r
	27	<P>\r
	28	</P>\r
	29	<H5 CLASS="c2">\r
	30	Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.<BR>\r
	31	Tel: 617-621-9500 Fax: 617-621-1703 URL: <A HREF=\r
	32	"http://www.openmarket.com/">http://www.openmarket.com/</A><BR>\r
	33	</H5>\r
	34	<HR>\r
	35	<H3>\r
	36	Abstract\r
	37	</H3>\r
	38	<P>\r
	39	FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI\r
	40	without introducing any of the new problems associated with writing applications to lower-level Web server\r
	41	APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key\r
	42	considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including\r
	43	applications written in popular scripting languages such as Perl), supporting both single-threaded and\r
	44	multi-threaded application programming, supporting distributed configurations for scaling and high\r
	45	availability, and generalizing the roles that gateway applications can play beyond CGI's\r
	46	"responder" role.\r
	47	</P>\r
	48	<P>\r
	49	For more information on FastCGI, including an interface specification and a module for the Apache server,\r
	50	visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
	51	</P>\r
	52	<H3>\r
	53	1. Introduction\r
	54	</H3>\r
	55	<P>\r
	56	The surge in the use of the Web by business has created great demand for applications that create dynamic\r
	57	content. These applications allow businesses to deliver products, services, and messages whose shape and\r
	58	content are influenced by interaction with and knowledge of users.\r
	59	</P>\r
	60	<P>\r
	61	This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway\r
	62	Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not\r
	63	all) of the performance problems with CGI, but are not designed to meet the need of business applications.\r
	64	When applied to business applications, Web server APIs suffer from these problems:\r
65	</P>\r
66	<UL>\r
67	<LI>\r
68	<B>Complexity.</B> Server APIs introduce a steep learning curve, with increased implementation and\r
69	maintenance costs.\r
70	</LI>\r
71	<LI>\r
72	<B>Language dependence.</B> Applications have to be written in a language supported by the server API\r
73	(usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing\r
74	server API.\r
75	</LI>\r
76	<LI>\r
77	<B>No process isolation.</B> Since the applications run in the server's address space, buggy\r
78	applications can corrupt the core server (or each other). A malicious or buggy application can compromise\r
79	server security, and bugs in the core server can corrupt applications.\r
80	</LI>\r
81	<LI>\r
82	<B>Proprietary.</B> Coding your application to a particular API locks you into a particular server.\r
83	</LI>\r
84	<LI>\r
85	<B>Tie-in to server architecture.</B> API applications have to share the same architecture as the server:\r
86	If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has\r
87	single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when\r
88	the server's architecture changes, the API will usually have to change, and applications will have to\r
89	be adapted or rewritten.\r
90	</LI>\r
91	</UL>\r
92	<P>\r
93	Web server APIs are suitable for applications that require an intimate connection to the core Web server, such\r
94	as security protocols. But using a Web server API for a Web business application would be much like using an\r
95	old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business\r
96	transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost\r
97	penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior\r
98	performance to boot. Nobody uses the old technology unless they are already locked into it.\r
99	</P>\r
100	<P>\r
101	FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI's performance problems.\r
102	The major implementation differences are:\r
103	</P>\r
104	<UL>\r
105	<LI>\r
106	FastCGI processes are persistent: after finishing a request, they wait for a new request instead of\r
107	exiting.\r
108	</LI>\r
109	<LI>\r
110	Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the\r
111	environment information, standard input, output, and error over a single full-duplex connection. This\r
112	allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the\r
113	FastCGI application.\r
114	</LI>\r
115	</UL>\r
116	<P>\r
117	FastCGI communicates the exact same information as CGI in a different way. Because FastCGI <I>is</I> CGI, and\r
118	like CGI runs applications in separate processes, it suffers none of the server API problems listed above.\r
119	</P>\r
120	<H3>\r
121	2. Migration from CGI\r
122	</H3>\r
123	<P>\r
124	Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the\r
125	protocol details from the developer. This library, which is freely available, makes writing FastCGI programs\r
126	as easy as writing CGI applications.\r
127	</P>\r
128	<P>\r
129	The application library provides replacements for the C language standard I/O (stdio) routines such as\r
130	<TT>printf()</TT> and <TT>gets()</TT>. The library converts references to environment variables, standard\r
131	input, standard output, and standard error to the FastCGI protocol. References to other files "fall\r
132	through" to the underlying operating system standard I/O routines. This approach has several benefits:\r
133	</P>\r
134	<UL>\r
135	<LI>\r
136	Developers don't have to learn a new API to develop FastCGI applications.\r
137	</LI>\r
138	<LI>\r
139	Existing CGI programs can be migrated with minimal source changes.\r
140	</LI>\r
141	<LI>\r
142	FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the\r
143	interpreter source code.\r
144	</LI>\r
145	</UL>\r
146	<P>\r
147	Here's a simple FastCGI application:\r
148	</P>\r
149	<BR>\r
150	<BR>\r
151	<PRE>\r
152	#include <fcgi_stdio.h>\r
153	\r
154	void main(void)\r
155	{\r
156	int count = 0;\r
157	while(FCGI_Accept() >= 0) {\r
158	printf("Content-type: text/html\r\n");\r
159	printf("\r\n");\r
160	printf("Hello world!<br>\r\n");\r
161	printf("Request number %d.", count++);\r
162	}\r
163	exit(0);\r
164	}\r
165	</PRE>\r
166	<P>\r
167	This application returns a "Hello world" HTML response to the client. It also keeps a counter of the\r
168	number of times it has been accessed, displaying the value of the counter at each request. The\r
169	<TT>fcgi_stdio.h</TT> header file provides the FastCGI replacement routines for the C standard I/O library.\r
170	The <TT>FCGI_Accept()</TT> routine accepts a new request from the Web server.\r
171	</P>\r
172	<P>\r
173	The application library was designed to make migration of existing CGI programs as simple as possible. Many\r
174	applications can be converted by adding a loop around the main request processing code and recompiling with\r
175	the FastCGI application library. To ease migration to FastCGI, executables built with the application library\r
176	can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the\r
177	execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.\r
178	</P>\r
179	<P>\r
180	Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language\r
181	interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix\r
182	platforms are available from the <I>www.fastcgi.com</I> Web site. The interpreters are backward-compatible:\r
183	They can run standard Tcl and Perl applications.\r
184	</P>\r
185	<H3>\r
186	3. Single-threaded and multi-threaded applications\r
187	</H3>\r
188	<P>\r
189	FastCGI gives developers a free choice of whether to develop applications in a single-threaded or\r
190	multi-threaded style. The FastCGI interface supports multi-threading in two ways:\r
191	</P>\r
192	<UL>\r
193	<LI>\r
194	Applications can accept concurrent Web server connections to provide concurrent requests to multiple\r
195	application threads.\r
196	</LI>\r
197	<LI>\r
198	Applications can accept multiplexed Web server connections, in which concurrent requests are communicated\r
199	over a single connection to multiple application threads.\r
200	</LI>\r
201	</UL>\r
202	<P>\r
203	Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- so many\r
204	developers will prefer to program in the familiar single-threaded style. By having several concurrent\r
205	processes running the same application it is often possible to achieve high performance with single-threaded\r
206	programming.\r
207	</P>\r
208	<P>\r
209	The FastCGI interface allows Web servers to implement <I>session affinity</I>, a feature that allows\r
210	applications to maintain caches of user-related data. With session affinity, when several concurrent processes\r
211	are running the same application, the Web server routes all requests from a particular user to the same\r
212	application process. Web server APIs don't provide this functionality to single-threaded applications, so\r
213	the performance of an API-based application is often inferior to the performance of the corresponding FastCGI\r
214	application.\r
215	</P>\r
216	<H3>\r
217	4. Distributed FastCGI\r
218	</H3>\r
219	<P>\r
220	Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run\r
221	remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to\r
222	systems that don't have Web servers.\r
223	</P>\r
224	<P>\r
225	Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can\r
226	communicate through the firewall to internal databases. For instance, an application might need to\r
227	authenticate incoming users as customers in order to give access to certain documents on the external Web\r
228	site. With FastCGI this authentication can be done without replicating data and without compromising security.\r
229	</P>\r
230	<H3>\r
231	5. Roles\r
232	</H3>\r
233	<P>\r
234	A problem with CGI is its limited functionality: CGI programs can only provide responses to requests. FastCGI\r
235	provides expanded functionality with support for three different application "roles":\r
236	</P>\r
237	<UL>\r
238	<LI>\r
239	<B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by\r
240	CGI today.\r
241	</LI>\r
242	<LI>\r
243	<B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the\r
244	client.\r
245	</LI>\r
246	<LI>\r
247	<B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as\r
248	performing a username/password database lookup).\r
249	</LI>\r
250	</UL>\r
251	<P>\r
252	Other roles will be defined in the future. For instance, a "logger" role would be useful, where the\r
253	FastCGI program would receive the server's log entries for real-time processing and analysis.\r
254	</P>\r
255	<H3>\r
256	6. Conclusions\r
257	</H3>\r
258	<P>\r
259	Today's Web business applications need a platform that's fast, open, maintainable, straightforward,\r
260	stable, and secure. FastCGI's design meets these requirements, and provides a logical migration path from\r
261	the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's\r
262	benefits without losing their existing investment in CGI applications.\r
263	</P>\r
264	<P>\r
265	For more information about FastCGI, visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
266	</P>\r
267	</BODY>\r
268	</HTML>\r
269	\r