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

Allow specifying default hostnames (instead of localhost) #838

Open
hmeine opened this issue Jan 18, 2020 · 4 comments
Open

Allow specifying default hostnames (instead of localhost) #838

hmeine opened this issue Jan 18, 2020 · 4 comments
Labels
needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically

Comments

@hmeine
Copy link

hmeine commented Jan 18, 2020

This seems to be related to #215 and #180, but is not a pure duplicate:
I would like to be able to create an alias or shell function for accessing a certain rest API requiring authentication. I started with

function girder {
    https --session=~/.girder_session.json girder.host.local.lan/api/v1/$1 ${@:2}
}

but my main problem is that I cannot change the HTTP method (e.g. to PUT or PATCH) this way. I would like to be able to have a different way of specifying the default host, so that I do not have to add a commandline parsing around httpie. And I do have some hope, since httpie already supports a default hostname, only that it's hardcoded to be localhost.

I see two potential solutions:

  1. Allow setting of default base_url #215 contains a small change introducing an environment variable for the default host, which would solve my issue.
  2. Another idea I had (more in the line of Custom User-Agent not remembered during session #180) would be to make the default hostname an optional part of the sessions. Maybe that could even be made to work with named sessions, by looking into a "default" host directory: ~/.httpie/sessions/default/<name>.json

With both solutions, the above shell function could be turned into a simple alias passing the desired --session parameter.

@isidentical isidentical added the needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically label Dec 28, 2021
@vergenzt
Copy link

vergenzt commented Apr 26, 2022

FYI, I've worked around this for local scripting use by defining a function (in Fish, as that's the shell I use). I'm still working out the kinks, but here's the basic structure:

function http
  argparse --ignore-unknown 'base-url=' -- $argv # extract --base-url if specified as option
  set opts (string match -rae  '^-' -- $argv) # extract args that start with '-' into $opts
  set rest (string match -raev '^-' -- $argv) # extract args that do not start with '-' into $rest
  command http $opts (string join $flag_base_url $rest[1]) $rest[2..-1] # put $opts before $rest
end

Note that this has meant that options that take an argument have to be joined with that argument with an equals sign instead of a space. So e.g. http --base-url=example.com --auth $USER:$PASS /test will fail because it'll translate to http --auth example.com/test $USER:$PASS.

Instead, with this workaround, you've gotta do either http --base-url=example.com --auth=$USER:$PASS /test with translates to http --auth=$USER:$PASS example.com/test.

@vergenzt
Copy link

vergenzt commented Apr 26, 2022

Hmm, I just realized as I was posting #838 (comment) that this doesn't work when an http verb (get, post, put, etc.) is explicitly passed as the first argument, as this function statically prepends $flag_base_url to the first non-option argument.

I think what I'll likely do is statically check if $rest[1] is in the list of expected http verbs → prepend $flag_base_url to $rest[2] if so, else prepend to $rest[1].

vergenzt added a commit to vergenzt/httpie that referenced this issue Apr 27, 2022
vergenzt added a commit to vergenzt/httpie that referenced this issue Dec 15, 2022
@MoyeMoixa
Copy link

This has been open for a while. Will it be released soon?

@vergenzt
Copy link

Draft PR remains open: #1377

I haven't had time nor motivation to push it to completion.

However AFAIK it has not received any official confirmation that it would be accepted if it's cleaned up. So if a maintainer would be willing to confirm they'd be comfortable with this change before anybody puts more effort in that would be nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically
Projects
None yet
Development

No branches or pull requests

4 participants