CITA 330 Section 10 Web Remoting Techniques

Web Remoting Web Remoting is a term used to categorize the technique of using JavaScript to directly make an HTTP request to the server and process the response.

Web Remoting Traditionally, Web browsers initiate HTTP requests, not scripts. The classical function of a Web browser is based on a synchronous request/response model where HTTP requests are made in response to the user clicking links, submitting a form, or typing in a URL. The browser processes the request by discarding the current page (including any running scripts), downloading a new page from the server, and then loading the new page in the browser for the user to view.

This is a time-consuming process, especially when you don’t need to display a whole new page. Web Browser Web Server Process request User clicks linkUser enters URL Process request User submits form user waits… Web Remoting

Often you only need to send a small amount of information to the server, or update a portion of the current page with a little data from the server. Web Remoting

To work around the limitations of this page- driven paradigm Web developers have constructed techniques to exploit URL- supporting HTML tags and CSS properties in non-traditional ways. Web Remoting

Every tag with a src or href attribute that can be used without reloading the entire page is a candidate, including,,,, and. You can exploit this fact to send information to the server by encoding that information in the URL query string. You can additionally have the server set a cookie in the response with information you need. Web Remoting

XMLHttpRequest While the techniques that use HTML tags (also called remote scripting) are often useful, they are, strictly speaking, a misuse of their intended design, and can sometimes be complicated to get working properly and uniformly across browsers.

XMLHttpRequest Alternatively, the XMLHttpRequest object provides full support for making asynchronous (the A in Ajax) HTTP requests including HEAD, POST, and GET, and can, despite its name, handle responses in plain text, XML, or HTML. This allows the Web application to process user’s input and respond with data from the server without having to make the user wait for an entire page to load.

Form Processing without XMLHttpRequest

Form Processing with XMLHttpRequest

Microsoft was the first to implement asynchronous request functionality in Internet Explorer version 5.0, released in March Microsoft first implemented the object as XMLHTTP, an ActiveX component in an XML library called MSXML. Mozilla ported the idea to their Mozilla 1.0 browser, released in May Mozilla decided to call their object XMLHttpRequest and make it native to the browser’s JavaScript interpreter. XMLHttpRequest

Apple followed later with a native implementation in Safari 1.2 (February 2004) and Opera added a native implementation in version 8.0 (April 2005) Internet Explorer 7 (October 2006) implemented a native replacement to XMLHTTP called XMLHttpRequest. XMLHttpRequest

Creating an XMLHttpRequest Object Using XMLHttpRequest is essentially a three-step process. 1.Create an XMLHttpRequest object. 2.Configure and submit your HTTP request to the server. 3.Process the server’s response.

Sending an HTTP Request Once you have created an instance of XMLHttpRequest, the API for using it is the same in all browsers. Using an XMLHttpRequest object is a multistep process. First initialize the object to specify what URL to request and how to use the object, then call the send() method to actually make the request, and finally, process the response.

void open(DOMString method, DOMString url, boolean async, DOMString user, DOMString password) method (required): A string that defines the HTTP method of the request, which essentially describes the operation to be performed on the resource identified by the URL of the request. Typical HTTP methods are HEAD, GET, and POST. url (required): A string defining the target URL of the request. XMLHttpRequest Methods

void open(DOMString method, DOMString url, boolean async, DOMString user, DOMString password) async (optional): A Boolean value indicating if the request should be made asynchronously. By default the value is true, which processes the request asynchronously. user (optional): A string identifying a user for a Web server that requires authentication. password (optional): A string identifying the user’s password. XMLHttpRequest Methods

void send(Object data) If the request was configured to be asynchronous then this method returns immediately; otherwise it blocks until the response is received. The optional parameter is sent as part of the request body. The parameter can be a DOM Document object, an input stream, or a string. The parameter is usually only used when sending a POST request with form data. XMLHttpRequest Methods

onreadystatechange An event handler that is invoked as the request changes state. An XMLHttpRequest object progresses through five states as the request is being processed. XMLHttpRequest Properties

readyState An integer value that is set to the current state of the request. The browser changes the readyState of an XMLHttpRequest object as the request is being processed, which causes the onreadystatechange event handler to be called allowing you to react to the change in state. Usually, the only state you care about is 4 Completed. XMLHttpRequest Properties

readyState 0 Uninitialized: The open() method hasn’t been called yet. 1 Loading: The open() method has been called, but the send() method has not. 2 Loaded: The send() method has been called, but the server has not responded yet. 3 Interactive: A partial response has been received. 4 Completed: The complete response has been received and the connection is closed. XMLHttpRequest Properties

responseText : The body of the server’s response as a string of text. The server can respond to the request with plain text, HTML, XML, whatever. As long as the request was successful, this value will get set to the response data in string form no matter what format came back. responseXML : If the response is an XML document (and the response Content-Type header is set to “text/xml”), then the XML will be parsed into a DOM Document object and assigned to this property. XMLHttpRequest Properties

status : An integer value containing the HTTP status code of the response. statusText : A string value containing the text description of the status code (“OK” for 200, “Found” for 302, etc.). XMLHttpRequest Properties

Processing the Response The HTTP response data is identified by the Content-Type header, which specifies a MIME (Multipurpose Internet Mail Extensions) type. Theoretically, you can respond to an XMLHttpRequest in any format that the browser supports, but the XMLHttpRequest object only has special handling for XML data.

Processing the Response The browser will automatically parse a response that is well-formed XML with the Content-Type header set to "text/xml", "application/xml", or any other MIME type that ends with "+xml" (like "application/xhtml+xml"). If the XML data is not well-formed or the Content-Type header is not set properly, then the XMLHttpRequest responseXML property will not contain a DOM Document object.

If the response does not contain XML, then the browser assigns the HTTP response body to the XMLHttpRequest responseText property and it’s up to you to parse the data, if needed. The most common response formats used in Ajax development are XML ("text/xml"), HTML ("text/html"), plain text ("text/plain"), JavaScript ("text/javascript"), and JavaScript Object Notation ("application/json"). Processing the Response

Plain text data is good for small pieces of data like a validation message. HTML data is useful if you need only need to update content within a single DOM node – meaning you can use innerHTML and not have to parse the HTML manually. XML and JSON are good for transferring several pieces of data that are to be used in various parts of the page or for calculations. Processing the Response

Web Remoting Pitfalls The Web has been around long enough that users are accustomed to certain conventions. –You expect to get a visual progress indicator from the browser when waiting for a page to load –You expect to be able to click the back button and see the last Web page you were viewing –You expect to be able to bookmark pages so you can return directly to them at a later time Ajax introduces forms of interaction that break these conventions.

Visual Feedback With the traditional use of HTTP, when a user clicks on a hyperlink the browser provides some form of visual feedback that work is being done, like a spinning image or a progress bar. When you use the XMLHttpRequest object the browser does not provide any indication to the user that something is happening. A simple fix for this is to display a text message or animated image while the XMLHttpRequest is being completed and hide the indicator when the request is complete.

Browsing History As a user surfs the Web, the browser stores the URLs for all the pages the user has visited in a cache, commonly called the history. The browser then enables the Back and Forward buttons to allow the user to navigate back and forward through the browsing history.

Browsing History When a request is made using XMLHttpRequest, the URL is not stored in the browser’s history. You can avoid this pitfall by designing your application such that elements that look like hyperlinks are traditional hyperlinks that do a page reload and get entered into the browser’s history. Elements of your application that use XMLHttpRequest don’t have to fool the user into thinking they should behave like a traditional hyperlink.

Bookmarking With static pages, the URL in your browser’s navigation bar can be bookmarked and you can return to that page by simply clicking on the bookmark. Therefore, users will expect this of your Ajax Web application as well. However, an XMLHttpRequest could be made and the response used to change a significant section of the page but the URL in the browser’s navigation bar will not change.

Bookmarking You can reduce your user’s expectations of bookmarking-ability by only changing content on the page that strictly has an “application” feel to it, but this will only take you so far. It’s important that you design for the ability to bookmark the state of your Web application even though you may have to provide a non-traditional way for the user to bookmark it.

Same-Origin Policy This policy prevents JavaScript code from reading or setting the properties of windows and documents that have a different origin than the document containing the script. The origin of a document includes the protocol, the domain name (host), and port of the URL from which the document was loaded. Documents belong to the same origin if and only if those three values are the same.

The only current, cross-browser exception to the same-origin policy applies to windows and frames. The domain property of the Document object, by default, contains the hostname of the server from which the document was loaded. JavaScript in two different windows or frames can change their domain property to the same domain to interact with each other. However, the domain property can only be set to a valid domain suffix of the default value. Same-Origin Policy