Issue 1:
Since the verify parameter is designed with the certificate stored on the filesystem, I have had to do some workarounds in my application, since I am expecting certificates to be passed in using environment variables. While experimenting with these workarounds, I noticed some strange behaviors.

Main Issue:

The docs claim that path/path-like objects are the intended use case, however, you are able to pass some things in that aren't path-like, and it is able to work.

You should definitely be able to just pass in a certificate as a variable, why is this not supported?

Please read the Reproduction Steps below, that is best way to understand the issue.

Expected Result

When using the verify= parameter, I expect to be able to pass in these types of objects:

string of path

os.PathLike

Current Error Message, when passing in a wrong Type:

TypeError: stat: path should be string, bytes, os.PathLike or integer, not _io.StringIO

Actual Result

Things passed in that could work:

certificate in string form, however only when using .read() function

path or pathlike of certificate

What happened instead.

Reproduction Steps

import requests
from io import StringIO
import os
import tempfile

## Get certificate stored in env variable
tls = os.getenv("TLS")

## Do some conversions of the certificate
# StringIO Form
f = StringIO(codecs.decode(tls, encoding="hex").decode())

# String Form
y = f.read()

# Tempfile Form
a = bytes.fromhex(tls)
fp = tempfile.NamedTemporaryFile()
fn = fp.name
fp.write(a)
fp.seek(0)
cert_path = fn

## Use the certificate in various ways:
requests.get("https://192.168.1.12:8080/v1/getinfo", headers=headers, verify=cert_path).json()
# Successful, most canonical way to do it

requests.get("https://192.168.1.12:8080/v1/getinfo", headers=headers, verify=f.read()).json()
# Successful, throws WARNING: InsecureRequestWarning: Unverified HTTPS request is being made to host '192.168.1.12'. # Adding certificate verification is strongly advised.
# Since it was successful, it seems the warning isn't valid, since an unverified HTTPS requests was not sent.

requests.get("https://192.168.1.12:8080/v1/getinfo", headers=headers, verify=y).json()
# Failure: OSError: Could not find a suitable TLS CA certificate bundle, invalid path: ...

System Information

$ python -m requests.help

{
"chardet": {
"version": "3.0.4"
},
"cryptography": {
"version": "3.2"
},
"idna": {
"version": "2.10"
},
"implementation": {
"name": "CPython",
"version": "3.8.5"
},
"platform": {
"release": "5.8.0-7642-generic",
"system": "Linux"
},
"pyOpenSSL": {
"openssl_version": "1010108f",
"version": "20.0.1"
},
"requests": {
"version": "2.25.0"
},
"system_ssl": {
"version": "1010106f"
},
"urllib3": {
"version": "1.25.10"
},
"using_pyopenssl": true
}

This command is only available on Requests v2.16.4 and greater. Otherwise,

please provide some basic information about your system (Python version,

operating system, &c).

Issue 2:
Since requests can be attached with an auth method, and there is oauth files in the package, so we can pass auth method to requests in order to archive auto auth function.

However, the code of oauth is conflicting with current trunk code.

Let's see

https://github.com/kennethreitz/requests/blob/develop/requests/models.py#L535

So if i pass in a dict object as post data, content-type will be set automatically.

Then see here

https://github.com/kennethreitz/requests/blob/develop/requests/auth.py#L81

If content-type is set, oauth won't work! It expects signing will be executed by manual operation!

Let's summarize all things:

Content-Type is set for the existence of non-plain dict object, oauth rejects to work for the existence of content-type.

WTF!

Either cancel automatically adding content-type or always sign the request without thinking about content-type will finally solve the problem.

Plz fix it.