ngnjs / net Goto Github PK

We need a URL parser/normalizer/etc for browsers. Node has the URL object (with both legacy and WHATWG/WC3 implementations).

Should this be a new high level class, i.e. new NGN.URL(...), part of the network lib, or considered a utility? Should it be part of NGNX?

It makes less sense to be a part of NGNX, since it is relevant to both backend and frontend logic.

It should be possible to specify proxy authorization headers in the same manner basic authorization headers are specified.

Similar to #14, response events should be available on the client/resource modules. For example:

API = new Resource(...)

// Listen for all responses
API.on('response', response => {
  console.log(`Recevied (${response.status}) ${response.responseText}`)
})

// Listen for 401 response status 
API.on('401', response => {
  console.warn('unauthorized access')
})

// Listen for 400 level status codes
API.on('4XX', response => {
  console.warn(`Recevied (${response.status}) ${response.responseText}`)
})

In most cases, responses will be handled directly by the request caller. Events allow global listeners to log responses, trigger additional response handlers, etc. For instance, many people are used to the axios HTTP library, which throws an error on 4XX responses. 4XX are a successful HTTP response indicating there was a some sort of network or api related problem, such as a 401 indicating a user can contact and endpoint but isn't allowed to do so. This library does not consider an HTTP response status code to be a JavaScript error, but it can still be useful to throw an application error when one of these types of responses occurs.

This can also be used to identify problems, modify the client/resource instance, and retry a request automatically (such as renewing an access token before retrying a failed request).

Finally, these events can be very useful for logging.

Is your feature request related to a problem? Please describe.
The get() method allows passing in a configuration object to set parameters on the Request, but the json() method does not.

Describe the solution you'd like
I'd like to be able to pass in a config object as an optional second parameter.

Describe alternatives you've considered
NONE

Additional context
I need to be able to run a request with mode: no-cors for local development. I could just use the get() method but I would like to take advantage of the json() method's automatic JSON parsing.

From ngn-core created by coreybutler : ngnjs/ngn-core#21

Provide support for attaching an SSL certificate to HTTP requests or adding a client SSL certificate to a network resource. Encryption password support is also necessary.

Servers may request certificates from the client, prompting selection. However; it should be possible to specify the certificate content, particularly as web crypto becomes more prominent (JWT's).

Make sure HTTP/2 and QUIC support are enabled in Node.

This package doesn't have a default file set. You can set it via jsdelivr, browser, or main field in package.json

From ngn-core created by coreybutler : ngnjs/ngn-core#22

A library of constants may help simplify network requests. This would likely be best as an extension to NGN instead of a core element of the library, since it is not required to make a network request.

Just a few examples:

• NGN.NET.PORT.HTTP refers to port 80
• NGN.NET.PORT.HTTPS & NGN.NET.PORT.TLS refer to port 443
• NGN.NET.PORT.LDAP refers to port 53
• NGN.NET.PORT.SLDAP refers to port 686
• NGN.NET.PORT.SSH refers to port 21
• NGN.NET.PORT.SMTP refers to port 25

These could also be aliased with friendly names like NGN.NET.PORT.EMAIL which could refer to the SMTP port.

The purpose of these constants is to simplify network connectivity for developers who are less familiar with common port values.

Additionally, HTTP status code constants/references may be useful.

A few examples include:

• NGN.NET.STATUS.OK refers to 200.
• NGN.NET.STATUS.SUCCESS refers to 2XX.
• NGN.NET.STATUS.FAILURE refers to 4XX and 5XX.
• NGN.NET.STATUS.DENIED refers to 401.

Is your feature request related to a problem? Please describe.
When developing locally it is sometimes helpful to be able to disable CORS. There isn't a simple, easy way to do that that I'm aware of at present.

Describe the solution you'd like
It would useful to have a global mode configuration option when instantiating a Resource. This would accept any of the values described here: https://developer.mozilla.org/en-US/docs/Web/API/Request/mode and apply them to all requests made by the Resource.

Describe alternatives you've considered
NONE

Additional context
NONE

The client/resource modules are based on the EventEmitter, but they don't currently emit/relay events.

It would be nice to have the client/resource emit events about the request so the following scenarios would work:

API = new Resource({...})

API.on('request', event => {
  console.log(`Method: ${event.method}`)
  console.log(`URL: ${event.URL}`)
  console.log(`Body: ${event.body}`)
})

API.on('post', event => {...})
API.on('get', event => {...})
API.on('put', event => {...})
API.on('delete', event => {...})

The primary use case for this functionality is logging, but it could also be used for security hooks. Ideally, a before (i.e. before.post) and after (just post) version of each event would be useful, allowing developers to potentially abort or modify requests before they're actually sent.

This could also be useful for post-processing data, such as augmenting the response body of a request before inserting the data into an application.

All of the major HTTP verbs should optionally return a promise if no callback method is specified.

When a request is signed, it currently sets an HTTP header called signature. It should be possible to customize this. For example, some API's require the header to be x-signature or part of the authorization header.

The Resource class contains an internal setTimeout/setInterval to monitor access tokens/emit events prior to expiration. This prevents instances of this class from closing. In unit test environments (like tappedout), this prevents tests from closing. A method to close the resource or stop monitoring would allow unit testers to resolve this edge case by calling Resource.close().