镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

WebView does not send custom request header after the first initial page load #8693

Closed

Description

@chiraggshah

The source prop for WebView allows for passing request headers. When the webview renders for the first time, the request headers are sent.

But when the links within that page are clicked, the headers are not sent to the server in the request header.
Similarly, when the goBack() method is called on the WebView, the request headers are not being sent.

Activity

  1. dunghuynh commented on Jul 17, 2016

    @dunghuynh

    +1. I got the same problem with version 30-rc

  2. dunghuynh commented on Jul 17, 2016

    @dunghuynh

    And it only exists on Android. My iOS app works normally.

  3. ghidinelli commented on Jul 18, 2016

    @ghidinelli

    We are seeing the problem on iOS

  4. chiraggshah commented on Aug 23, 2016

    @chiraggshah
    ContributorAuthor

    Any update on this? Facing the problem on both iOS and Android. Or anyone can point me in the right direction on how to fix this?

  5. ghidinelli commented on Sep 4, 2016

    @ghidinelli

    Reliable HTTP headers are important for many apps / APIs to work. Any update on this?

  6. karankurani commented on Nov 26, 2016

    @karankurani
  7. lacker commented on Nov 30, 2016

    @lacker
    Contributor

    Can you provide a sample rnplay.org app that reproduces this problem?

  8. ghidinelli commented on Dec 1, 2016

    @ghidinelli

    I'll see if @chiraggshah can provide a sample from our application however he's on holiday for the next 2.5 weeks.

  9. peichao01 commented on Dec 10, 2016

    @peichao01

    react-native-cli: 1.3.0
    react-native: 0.38.1

    Android has the same problem, not test iOS.

  10. alkhanna commented on Dec 28, 2016

    @alkhanna

    I was wondering if anyone has a workaround or fix for this issue?

  11. chiraggshah commented on Dec 29, 2016

    @chiraggshah
    ContributorAuthor

    @alkhanna : I have written a blog with the workaround for this. http://blog.bigbinary.com/2016/07/26/passing-request-headers-on-each-webview-request-in-react-native.html

    @lacker : I am not sure how to host own server which logs the headers received on each request using rnplay.org. Instead, I can paste a sample app here.

    Server:

    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);
    

    Webview Code:

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

    After starting the node server, the logs show the headers being passed for the first request sent by webview. But on subsequent page clicks, the header is not sent.

    Let me know if I can be more descriptive, and I will do as required.

  12. evanidul commented on Mar 2, 2017

    @evanidul
  13. chiraggshah commented on Apr 17, 2017

    @chiraggshah
    ContributorAuthor

    @satya164 : Can you point me to the right person who possibly would have the insight on how to fix this? This is a long time issue and has not received much attention.

  14. chiraggshah commented on Apr 17, 2017

    @chiraggshah
    ContributorAuthor

    Or someone can guide me on how to fix it or where to start looking? That too would be a good start.

  15. ismdcf commented on Jun 15, 2017

    @ismdcf
  16. 21 remaining items

  17. gerow-x commented on Mar 12, 2018

    @gerow-x
  18. UsabilitySoft commented on Mar 14, 2018

    @UsabilitySoft
  19. jr-k commented on Apr 5, 2018

    @jr-k
  20. rdeift commented on Apr 10, 2018

    @rdeift
  21. banichols commented on Apr 14, 2018

    @banichols

    +1

    For anyone that needs this for basic authentication, in iOS you can set the authentication as part of the URL: https://user:password@example.com . Unfortunately this does not work for Android, for that I had to create a custom WebView and implement onReceivedHttpAuthRequest for its web client.

  22. mausworks commented on May 8, 2018

    @mausworks

    +1, running into this issue as well, it's extremely frustrating. Any updates?

    Given how common hybrid apps are, and how common Basic Authentication is, I honestly think this deserves more attention. Taking into consideration that this issue has been open for almost two years now …

    If the intention of source.headers is to simply provide custom headers with the first request, then you could provide a defaultHeaders-property for the web view, and still maintain backward compatibility. I would certainly not expect the "source headers" to get passed with each consecutive request.

    A more "catch-all" solution would be to provide a onRequest-callback, where the user can modify the request as they see fit, for instance:

    <WebView 
      onRequest={req => req.addHeader('Authorization', 'Basic c2VyaW91c2x5Ond0Zg==')}
      />
  23. wuyunqiang commented on May 14, 2018

    @wuyunqiang
  24. shopshow commented on Jun 19, 2018

    @shopshow
  25. jamonholmgren commented on Sep 9, 2018

    @jamonholmgren
    Collaborator

    Migrated to react-native-webview/react-native-webview#4, so we can close this issue.

  26. Titozzz commented on Sep 26, 2018

    @Titozzz
    Collaborator

    Closing here but we are committed to fix this and keep discussing on the new repo

  27. locked as resolved and limited conversation to collaborators on Dec 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Component: WebViewRelated to the WebView component.Help Wanted :octocat:Issues ideal for external contributors.Resolution: LockedThis issue was locked by the bot.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions