HTTP request headers on each WebView request

July 26, 2016

Using WebView in a React Native application allows us to reuse already built web pages.

HTTP Headers are name/value pairs that appear in both request and response messages. The purpose of headers is to supply the web server with additional information and control how content is returned.

In React Native, while opening web pages via WebView Component, we can pass headers to the HTTP request. Refer to our previous blog for more on this.

<WebView
  source={{
    uri: "http://localhost:3000",
    headers: { "custom-app-header": "react-native-ios-app" },
  }}
/>

But there is a bug. On subsequent requests from inside the WebView, the headers are not passed in the request.

First, let's try to understand by recreating the bug. We have created a simple node server which will act as the backend for the application and log the request along with the custom header.

Here is our server.js

var http = require("http");
var port = 9000;

function logRequest(request) {
  console.log("Processing request for: ", request.url);
  console.log("Custom Header: ", request.headers["custom-app-header"]);
  console.log("Request Processed\n");
}

http
  .createServer(function (request, response) {
    response.writeHead(200, { "Content-Type": "text/html" });
    switch (request.url) {
      case "/":
        response.write(
          "<html><body>Welcome<a href='/bye'>Bye</a></body></html>"
        );
        logRequest(request);
        break;
      case "/bye":
        response.write("<html><body>Bye<a href='/'>Welcome</a></body></html>");
        logRequest(request);
        break;
      default:
        break;
    }
    response.end();
  })
  .listen(port);

As we can see, the welcome page has a link to bye and vice versa. Let's start the node server by running node server.js.

When we run the app on the simulator, the welcome page opens up, and in the server log, we can verify that the request header is being passed.

Processing request for:  /
Custom Header:  react-native-ios-app
Request Processed

But when we click on the Bye link from the Welcome page, the server doesn't receive the request header, which can be verified from the log.

Processing request for:  /bye
Custom Header:  undefined
Request Processed

And it can be verified again that for any subsequent clicks the request header does not get passed. We can click on Welcome and check the log again.

Processing request for:  /
Custom Header:  undefined
Request Processed

We recently encountered this bug and created an issue here. Until the issue is fixed, we have found a workaround.

Workaround

WebView provides a prop onLoadStart which accepts a function that is invoked when the WebView starts loading.

We can use this prop to know when a link is clicked and then re-render the WebView component with the new url. Re-rendering the WebView component will load the page as if it's the first page and then the request headers would be passed.

We know that in React, a component re-renders itself when any of its state changes. The only thing which changes here is the url, so let's move the url to a state and initialize it to the Welcome page which is the root of the application. And then use the onLoadStart prop to change the url state to the clicked url.

Here's the new code.

class testApp extends Component {
  state = {
    url: "http://localhost:3000",
  };

  render() {
    return (
      <WebView
        onLoadStart={(navState) =>
          this.setState({ url: navState.nativeEvent.url })
        }
        source={{
          uri: this.state.url,
          headers: { "custom-app-header": "react-native-ios-app" },
        }}
      />
    );
  }
}

Now when we run the app, we can verify in the backend that the request headers are being sent even when we click on Bye link.

Processing request for:  /bye
Custom Header:  undefined
Request Processed

Processing request for:  /bye
Custom Header:  react-native-ios-app
Request Processed

One thing to note here is that, when we click on the Bye link, the request is not intercepted from reaching the server. We are just resending the request by means of a component re-render with the new url.

Hence in the log, we see two requests. First request took place when user clicked on the link, and the second request occurred when the component got re-rendered with the required request headers.

This workaround might help us to pass the request headers which we intend to send to the backend server until the issue gets fixed.

If this blog was helpful, check out our full blog archive.

HTTP request headers on each WebView request

Workaround

Stay up to date with our blogs.