Custom Headers

[KernelDeimos]

Hello, I'm opening a discussion for custom headers, which is a highly requested feature for http-server.

[KernelDeimos]

#887 has been merged. #885 suggested some alternative syntax (semicolon-separated values) which I'd like to also incorporate has long as it doesn't conflict with the curl convention used by 887 or valid characters for the header names and values themselves.

[KernelDeimos]

@dxdxdt can you look into this? cli.test.js fails when I run using npx tap test/cli.test.js

 FAIL  test/cli.test.js 5 failed of 16 1.377s
✖ single --header option is applied > test unfinished
  test/cli.test.js                                                                                        
  132   });                                                                                               
  133 }                                                                                                   
  134                                                                                                     
  135 test('single --header option is applied', (t) => {                                                  
  ━━━━┛                                                                                                   
  136   t.plan(4);                                                                                        
  137                                                                                                     
  138   doHeaderOptionTest(t,                                                                             
  139     ['--header=X-http-server-test-A: hello'],                                                       
  Object.<anonymous> (test/cli.test.js:135:1)

✖ single --header option is applied > test count(0) != plan(4)
  test/cli.test.js                                                                                        
  133 }                                                                                                   
  134                                                                                                     
  135 test('single --header option is applied', (t) => {                                                  
  136   t.plan(4);                                                                                        
  ━━━━━━━━┛                                                                                               
  137                                                                                                     
  138   doHeaderOptionTest(t,                                                                             
  139     ['--header=X-http-server-test-A: hello'],                                                       
  140     { 'x-http-server-test-a': 'hello' }                                                             
  --- expected   
  +++ actual     
  @@ -1,1 +1,1 @@
  -4             
  +0             

✖ child test left in queue: single -H option is applied
✖ child test left in queue: mix of multiple --header and -H options are applied
✖ child test left in queue: empty header value is allowed (RFC 7230)

Asserts:  11 pass  5 fail  16 of 16 complete
Suites:    0 pass  1 fail    1 of 1 complete

[dxdxdt]

Kindly return with the environment you're testing with so I can reproduce it. I only tested it in Linux.

✖ single --header option is applied > test unfinished

Looks like it hung somewhere.

The socket part of the code is highly OS dependent so I saw this coming. As with many things, I hacked my way through to making the test work, gotta admit. I'm really not sure if there should be tests for this feature, but let's see how it goes.

• The selection of the port
• IPV6_V6ONLY socket option (Binding the socket to an empty address string to create dual stack TCP socket is a Linux thing)
• Machine too busy

To name a few. Could be more.

[dxdxdt]

@KernelDeimos Hi,

It's hard to determine the cause in the log you posted, but as I was running the test myself on my local machine, I realised that the tests sometimes fail because the program fails to bind the server socket. During the run, the process exits and starts again quite aggressively. And to make the matters worse, the tests cannot be run in parallel because the program tries to bind to from 8080 incrementally. This isn't so efficient, when it comes to running the tests.

Just occurred to me that we can solve the issue by binding to the TCP port 0 for testing purposes. The kernel will select a port from the ephemeral range. This should be the standard on all platforms. The test unit can parse the output to get the port for testing.

If the problem is still there and you'd want me to fix it, please open an issue. Otherwise, let's just call it and forget about it.