Tim Perry

Hey Jim YT Chen, have you tried http://httptoolkit.tech/view/ruby/ as an alternative to HttpLog? It covers a very similar use case (capturing & viewing sent Ruby HTTP), but it’s got a proper UI & tools and doesn’t require any of those code changes at all. Let me know what you think :-)

Debug all HTTP(S) sent by git, npm, apt-get, or anything else

The command line is powerful, but can be hard to understand, and extremely hard to debug. Ever run a command, see it fail with a cryptic error, and have no idea why?

Better tools can help you understand what’s really going on. They can let you see inside the command you’re running to understand how it’s communicating, see what data it’s working with, and debug it in depth.

Excitingly I’ve just shipped one-click terminal interception to do exactly this with HTTP Toolkit, for HTTP and HTTPS, to show you everything your CLI is sending and ...

HTTP View is a beautiful, free & open-source HTTP inspector. This is the first release of HTTP Toolkit, and lets you intercept HTTP or HTTPS traffic with one click, explore & examine that traffic up close, and discover exactly what your code (or anybody else’s) is sending.

Want to dive right in? Download it now.

HTTP Toolkit is a project that I’ve been working on for a while, to build an open-source suite of tools for HTTP development. The goal is to intercept & examine HTTP, edit it live, analyse flows of HTTP requests to audit performance and security, and rapidly prototype HTTP cl...

I just hit this problem in my own VPN implementation (open source, if anybody wants a working example).

In my case, this was because I was writing TCP packets back to the VPN interface that were larger than expected, because my code wasn't properly handling the max segment size.

This wasn't due to some general purpose buffer waiting to flush, so packets that were too large for the receiving application would fail with ENOBUFS forever.

Although I can't find it documented anywhere, I expect this is the cause in general: you'll hit an ENOBUFS if you try to write any packet to the VPN that's indiv...

It depends on what exactly is happening in loadUsers, but it's likely that you've forgotten to a return statement there.

If you change loadUsers to return the promise for the user's it's loading, your code should start working nicely.

The main problem you have currently is that the type of FormErrors says that it has a key matching every key of V, and until the reduce finishes, that's not true.

You have a couple of options:

• Pass generics to reduce to make the return type Partial<FormErrors<V>>, and cast to FormErrors at the end:

  export function getInitialErrors<V extends KeyValue> (data: V): FormErrors<V> { return Object.keys(data).reduce<Partial<FormErrors<V>>>((acc, key) => ( { ...acc, [key]: [] } ), {}) as FormErrors<V> } 

  You could simply a little by now dropping the f...

Can you see the full response you're receiving?

It's not certain, but it seems likely that CORS headers aren't being included because the request is actually returning some other kind of error, and that in that case the CORS headers aren't being included. I.e. the CORS issue is probably hiding a separate error from you.

I would take a look in the browsers network tab to try and see the full response when it's failing, as that response might have more info, or using an HTTP inspection tool like HTTP Toolkit (full disclosure: this tool is one I've been building myself).

You could also try making ...