get/post method will convert some parameter in url into capital letter

get/post method will convert some parameter in url into capital letter

## Expected Result

It should send parameter same as I set in the URL

## Actual Result

It will convert"https://xxx.yyy/index.html?a=%2f" into "https://xxx.yyy/index.html?a=%2F" notice that final 'F'

## Reproduction Steps

At first,I found this problem when test a site which will return an 302,I found that because of parameter(_%2f_) changed ,the 302 location changed with it,in normal circumstances,it shouldn't be a problem because _%2F_ and _%2f_ will both be converted to "/" after urldecode,but in my case,it will make a difference,I don't know how the website work,but when I Get url returned by 302 with _%2F_ one,it shows 500 internal error,while use the _%2f_ one is fine,it is sure a bug about requests,because the parameter in url is Case Sensitive,so it shouldn't be changed.


In order to prove that, I wrote a urllib version get, and the result are different indeed.
This shows the difference between the 302 location.

![z](https://user-images.githubusercontent.com/49085201/91714485-65399a00-eb7b-11ea-91c7-9af2e2867df4.png)

This is the package captured by wireshark, you can see that the requests version get convert the %2f into %2F while the urllib version not

![批注 2020-08-31 191750](https://user-images.githubusercontent.com/49085201/91714596-a467eb00-eb7b-11ea-9aba-5ef6389b014b.png)


## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.8.5"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.24.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.10"
  },
  "using_pyopenssl": false
}
```


Part of URL normalization is uppercasing percent-encoded hex characters per RFC 3986. Service should handle both cases.

> Part of URL normalization is uppercasing percent-encoded hex characters per RFC 3986. Service should handle both cases.

Indeed,but I still don't think reuests.get/post should change case in url,is there anyway to avoid that?

You can use the prepared request flow, but relying on that to _not_ normalize URLs is also a bad idea. Your service should be written for all web-clients not just ones you make work for you.

> You can use the prepared request flow, but relying on that to _not_ normalize URLs is also a bad idea. Your service should be written for all web-clients not just ones you make work for you.

Yes,but the fact is that in most cases we can't control or rewrite the service(especially we just want to crawl data from some site)

> Part of URL normalization is uppercasing percent-encoded hex characters per RFC 3986. Service should handle both cases.

And yes,service **should** handle both,but it just didn't(like the one I'm dealing with),and in most cases(especially the server isn't ran by us),it really makes people upset

Hi @tjc0726,

As Seth and Sigmavirus24 have pointed out, Requests will use the correct behavior by default which we'd like to maintain. We've provided an escape hatch for this with PreparedRequests which should allow you write a few line function to meet any abnormal requirements/bugs of a third party server.

Going to resolve since it doesn't look like there's any changes we would want to make in this case.