Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle N targets #2

Closed
wants to merge 6 commits into from
Closed

Conversation

hackergrrl
Copy link

In addition to handling N targets, I also made a few other changes while digging around:

  • More standard/unixy USAGE format string
  • Writes all usage & general errors to stderr rather than stdout
  • URL validation (url.Parse() doesn't do validation)
  • More comments throughout
  • Returns 504 Gateway Timeout when all targets fail (rather than 404 Not Found)

Handling N targets ended up being a significant refactor, so it was difficult to separate that change from the above bullet pointed items. I can try and pull them all apart into separate commits, but they're all small things and shouldn't be too hard to examine inline.

failed := false
for i, v := range targets {
// Verify the target is HTTP or HTTPS.
if !strings.HasPrefix(v, "http://") && !strings.HasPrefix(v, "https://") {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would rip this out into a separate function: ValidateTarget or something

@whyrusleeping
Copy link
Owner

now that #1 is merged, give this one a rebase and i'll CR/M

Standard USAGE format
Writes usage & general errors to stderr
**Handles N targets**
URL validation (url.Parse doesn't do validation)
Generally more comments throughout
Returns 504 Gateway Timeout when all targets fail (rather than 404 Not
Found)
1. When 'failed' is closed !ok will be true -- we weren't properly
   hitting that case and the connection would stay open.
2. Cancels the request when a bad response code is hit.
@hackergrrl
Copy link
Author

Updated. Please take another look @whyrusleeping!

@@ -7,142 +7,150 @@ import (
"net/http"
"net/url"
"os"
"reflect"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Things that make me say "here we go..." for $200 Alex.

@@ -8,141 +8,131 @@ import (
"net/url"
"os"
"strings"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, reflection isn't necessary here. Let's just use a single channel.

resp_b <- resp
// Wait for a successful response (or failures across the board).
for {
chosen, value, _ := reflect.Select(cases)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i really feel like you could get away without using reflection here. Have one channel that a goroutine can send its index on when its done or something, then can grab the response from an array by its index.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants