starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 09:16:03 +03:00

[GH-ISSUE #2058] [feature]: explicit UI for protocol (e.g. http / https) #674

New issue

Closed

opened 2026-03-16 16:38:49 +03:00 by kerem · 7 comments

kerem commented

2026-03-16 16:38:49 +03:00

Owner

Originally created by @slifty on GitHub (Jan 6, 2022).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/2058

Originally assigned to: @RishabhAgarwal-2001 on GitHub.

Is there an existing issue for this?

I have searched the existing issues

Summary

Thank you for the wonderful project!

As a new user it took me a little while to figure out why my calls to localhost or 127.0.0.1 weren't working, even with the browser extension installed. I eventually tried typing http:// before the domain and it worked.

I think of the URL input the same way as I think of the browser URL input (but with the ability to specify method, body, header, etc). Given that, I was expecting the request to work even without an explicit specification of http://.

I appreciate there may be a use case for explicitly not having a protocol specified in a request, so maybe this could be accomplished with a new UX element that provides a select dropdown, defaulting to http, providing http and https as pre-provided values, but also capable of freeform input and editing as a text field?

Why should this be worked on?

It seems safe to bet that 99.99% of the time your users are going to want either http or https prefixed to their URLs. A reasonable portion of new users (and even veteran users) will probably not realize / remember that http has to be manually entered as part of the URL the first time they try.

The space will have to be taken up regardless (since http:// will have to be manually typed), so having a UX element would:

Save keystrokes.
Communicate the requirement of a protocol selection.
Achieve that requirement without user input.

This will also help new users verify their setup faster -- right now a new user would have reasonable cause to assume that the failed call is due to misconfiguration of the browser extension (or server) as opposed to realizing that the request itself has simply been improperly formed.

Originally created by @slifty on GitHub (Jan 6, 2022). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/2058 Originally assigned to: @RishabhAgarwal-2001 on GitHub. ### Is there an existing issue for this? - [X] I have searched the existing issues ### Summary Thank you for the wonderful project! As a new user it took me a little while to figure out why my calls to `localhost` or `127.0.0.1` weren't working, even with the browser extension installed. I eventually tried typing `http://` before the domain and it worked. I think of the URL input the same way as I think of the browser URL input (but with the ability to specify method, body, header, etc). Given that, I was expecting the request to work even without an explicit specification of `http://`. I appreciate there may be a use case for explicitly not having a protocol specified in a request, so maybe this could be accomplished with a new UX element that provides a select dropdown, defaulting to http, providing `http` and `https` as pre-provided values, but also capable of freeform input and editing as a text field? ### Why should this be worked on? It seems safe to bet that 99.99% of the time your users are going to want either http or https prefixed to their URLs. A reasonable portion of new users (and even veteran users) will probably not realize / remember that `http` has to be manually entered as part of the URL the first time they try. The space will have to be taken up regardless (since http:// will have to be manually typed), so having a UX element would: 1) Save keystrokes. 2) Communicate the requirement of a protocol selection. 3) Achieve that requirement without user input. This will also help new users verify their setup faster -- right now a new user would have reasonable cause to assume that the failed call is due to misconfiguration of the browser extension (or server) as opposed to realizing that the request itself has simply been improperly formed.

kerem

2026-03-16 16:38:49 +03:00

closed this issue
added the
feature
label

kerem commented

2026-03-16 16:39:05 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jan 6, 2022):

This seems like a genuine UX improvement though, I'd suggest not to introduce a drop-down for http and https. Instead, appending https by default to URLs without a protocol and or unless it's mentioned http. What do you think?

@liyasthomas commented on GitHub (Jan 6, 2022): This seems like a genuine UX improvement though, I'd suggest not to introduce a drop-down for `http` and `https`. Instead, appending `https` by default to URLs without a protocol and or unless it's mentioned `http`. What do you think?

kerem commented

2026-03-16 16:39:10 +03:00

Author

Owner

@slifty commented on GitHub (Jan 7, 2022):

That makes sense (I was absolutely just spitballing regarding the drop down)

Regarding default of HTTP vs HTTPS -- phewf this is a tough one.

I appreciate the merit of HTTPS default from a security perspective. That said if a primary use case is testing development environments I don't know if prepending https by default would address the concern raised by the issue. I think it's a common pattern to develop services over plain HTTP and rely on the production / deployment to provide an HTTPS wrapper / proxy around that service.

All this is to say that I don't think invisibly prepending an HTTPS default would fix the "I don't usually think to type http://localhost" problem.

So, ditch the dropdown, but maybe some visual element would let us have both?

The merit of some form of visual element is that it is explicit -- the user knows this will be served over http or https and in cases of default protocol specification (or even when protocol is explicit) they would be less likely to be (A) confused why an HTTPS request to an HTTP server it doesn't work or (B) unaware their request is being sent over a less secure protocol.

What about taking inspiration from how browser URL bars function already?

When HTTPS is being used (be it explicit OR by default) a lock could appear that, when hovered over, says "this request will be sent over https". In cases where a protocol wasn't specified it could include an extra line saying something like (https is used when no protocol is specified).

And an unlocked lock when HTTP is being used (also warning the user that their network traffic is not being encrypted, which might be a good note anyway).

^^ If you happened to pick http as the default you could do the same type of (http is used when no protocol is specified) message.

Any of that sound like it has potential?

@slifty commented on GitHub (Jan 7, 2022): That makes sense (I was absolutely just spitballing regarding the drop down) Regarding default of HTTP vs HTTPS -- phewf this is a tough one. I appreciate the merit of HTTPS default from a security perspective. That said if a primary use case is testing development environments I don't know if prepending https by default would address the concern raised by the issue. I think it's a common pattern to develop services over plain HTTP and rely on the production / deployment to provide an HTTPS wrapper / proxy around that service. All this is to say that I don't think invisibly prepending an HTTPS default would fix the "I don't usually think to type http://localhost" problem. --- So, ditch the dropdown, but maybe *some* visual element would let us have both? The merit of some form of visual element is that it is explicit -- the user knows this will be served over `http` or `https` and in cases of default protocol specification (or even when protocol is explicit) they would be less likely to be (A) confused why an HTTPS request to an HTTP server it doesn't work or (B) unaware their request is being sent over a less secure protocol. What about taking inspiration from how browser URL bars function already? <img width="474" alt="image" src="https://user-images.githubusercontent.com/208884/148480548-da34957a-2711-419a-bf2f-6a58979e134b.png"> When HTTPS is being used (be it explicit OR by default) a lock could appear that, when hovered over, says "this request will be sent over https". In cases where a protocol wasn't specified it could include an extra line saying something like `(https is used when no protocol is specified)`. And an unlocked lock when HTTP is being used (also warning the user that their network traffic is not being encrypted, which might be a good note anyway). ^^ If you happened to pick `http` as the default you could do the same type of `(http is used when no protocol is specified)` message. Any of that sound like it has potential?

kerem commented

2026-03-16 16:39:15 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Jan 11, 2022):

@slifty @liyasthomas

I am not a big fan of things like this being implicit. So what about a behaviour like this:

[The UI has no changes from the current UI]

User inputs the URL without a protocol definition
User clicks the send button
Hoppscotch checks the URL string and looks for the presence of the Protocol Definition
- Nothing happens if a protocol is already defined
- If a protocol is not defined
  - Check if the domain is a localhost domain (localhost/127.0.0.1) if so, append http protocol definition to the URL entry field
  - If not a localhost domain, append https protocol definition to the URL entry field
Hoppscotch runs the request with the updated URL entry

This way the user gets an immediate feedback on the action Hoppscotch performed meanwhile not adding more elements to the UI.

@AndrewBastin commented on GitHub (Jan 11, 2022): @slifty @liyasthomas I am not a big fan of things like this being implicit. So what about a behaviour like this: [The UI has no changes from the current UI] 1) User inputs the URL without a protocol definition 2) User clicks the send button 3) Hoppscotch checks the URL string and looks for the presence of the Protocol Definition - Nothing happens if a protocol is already defined - If a protocol is not defined - Check if the domain is a localhost domain (localhost/127.0.0.1) if so, append `http` protocol definition to the URL entry field - If not a localhost domain, append `https` protocol definition to the URL entry field 4) Hoppscotch runs the request with the updated URL entry This way the user gets an immediate feedback on the action Hoppscotch performed meanwhile not adding more elements to the UI.

kerem commented

2026-03-16 16:39:20 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jan 11, 2022):

Sounds good to me

@liyasthomas commented on GitHub (Jan 11, 2022): Sounds good to me

kerem commented

2026-03-16 16:39:25 +03:00

Author

Owner

@slifty commented on GitHub (Jan 12, 2022):

Thank you @AndrewBastin that is a perfect improvement (and I appreciate the desire to not touch universal UI without really really good reason! Great solution.)

@slifty commented on GitHub (Jan 12, 2022): Thank you @AndrewBastin that is a perfect improvement (and I appreciate the desire to not touch universal UI without really really good reason! Great solution.)

kerem commented

2026-03-16 16:39:30 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Jan 17, 2022):

@RishabhAgarwal-2001 you can work on this

@AndrewBastin commented on GitHub (Jan 17, 2022): @RishabhAgarwal-2001 you can work on this

kerem commented

2026-03-16 16:39:35 +03:00

Author

Owner

@RishabhAgarwal-2001 commented on GitHub (Jan 17, 2022):