Closed cedrick-ah closed 1 week ago
This is expected behaviour at the moment. You must supply a request context that has the fully qualified URL. The library isn't designed/intended to accept the raw HTTP IncomingMessage
object from Node, it's expecting some translation to be done by the application layer.
As per the spec (and the README), it is the job of the application to construct the contexts and that is outside the scope of the spec.
This is because it's not always trivial to determine the true URL for a request (eg: when the application is behind a proxy), and a library making any assumptions about how to determine how to construct the URL would open itself up to security risks.
For example, if we assume that the host
header is the domain to use, then behind a proxy this could be a completely different domain to where the request was made to. So the natural assumption is then to use the x-forwarded-host
header (if it is available) and only use the host
header if there's no forwarded header. Unfortunately, this has 2 problems - 1. What if your proxy uses a different header to record the original hostname - then this doesn't work. 2. What if the application isn't behind a proxy? An attacker may be able to abuse this logic by simply adding their own x-forwarded-host
header to the request.
It has to be up to the application to make decisions about how the URL is constructed and what parameters are trusted by the header-signing logic to be able to be secure and predictable.
tl;dr: This is expected behaviour, you need to transform your raw incoming request to a compliant object for the library.
I got it.
It is possible that doing this:
can lead to this error:
/my_url is the value of req.url when I receive the request from the client. The req.url in my http message is not in a valid URL format
protocol://host:[port]/path
as attended by the code but is just limited to/path
leading to this error.Here is the incoming message(request object):