Send GET HTTPS request but get 403 forbidden response, why?

前端 未结 2 1985
爱一瞬间的悲伤
爱一瞬间的悲伤 2021-02-11 08:15

Below is the URL I send to the WS after the handshake is done

    \"https://ekp.truefriend.com/COVIWeb/gate/AutoAuthentication.aspx?UserID=DP0001&BackUrl         


        
2条回答
  •  挽巷
    挽巷 (楼主)
    2021-02-11 08:51

    As I was saying in a comment to another answer, this has nothing to do with trusting the server's certificate or not. If you get an HTTP response, even if it's a 403, that means that the HTTP connection was established, which also means that the underlying SSL/TLS connection was established. If your client doesn't trust the server certificate, the SSL/TLS connection will close before any HTTP traffic happens.

    I'd try a few things:

    • Remove the Content-Length header. It's a GET request, so it doesn't have an entity. Implying a 0-length entity might confuse the server.
    • Try to set a User-Agent header to simulate the request as coming from a browser.
    • More generally, look at the headers a browser that work would send and try to reproduce them. (Try Accept header as well, that might be the cause of your problem with Chrome.)

    EDIT: (other potential problem, more likely to be the cause)

    If you urlstring variable really contains "https://ekp.truefriend.com/COVIWeb/gate/...", that's where the problem comes from.

    When you send an HTTP GET the request should be like this:

    GET /COVIWeb/gate/... HTTP/1.1
    Host: ekp.truefriend.com
    

    Not:

    GET https://ekp.truefriend.com/COVIWeb/gate/... HTTP/1.1
    

    (that's only for requests via a proxy, and doesn't apply to the HTTPS requests anyway.)

    If you're using HTTP 1.0, you won't use the Host header, but it shouldn't really matter (unless that host serves multiple virtual hosts, which it can do, even over HTTPS). Consider using HTTP/1.1 if you can, although you may have to deal with closing the connection (content-length or chunked encoding perhaps).

提交回复
热议问题