Hacker News Reader

Comment by Zak | Hacker News Reader

I think the best thing to do is check the URL server-side. If it doesn't contain a protocol, add http://, otherwise keep the supplied protocol.

View on HN

You should always check serverside, but this post is about the user experience of entering the url, not about what happens to it once sent to the server.

The letters http:// help I think, they suggest what's supposed to go in the field. A lot of people don't know what "url" means but they recognize the http://.

Good point. This is where a light gray "http://something.com/ in the background of the text field (disappears on focus) is nice.

The protocol tells the browser which port to connect to on the server. That can't be done server-side.

In this case, where you're typing the URL in a form, presumably as some sort of content management system, you're not telling your browser to go directly to the URL but rather saying 'I want to use this resource, it's at this URL'.

Before it uses that URL for anything, the server should process it, and if it's missing something like a protocol, add in a good default like http.

It never even gets to a server if it doesn't have a protocol. The browser would have no idea what to do with it. It wouldn't even know how to understand it.

Is:

  foo@bar.com

  mailto:foo@bar.com
  or
  ftp://foo@bar.com
  or
  http://foo@bar.com

Each one of those does something totally different, and all are legal.

The browser can add a default though - and it does.

It's a text field in a form. The browser doesn't need to have any ideas about what to do with it except submit it to the server.

Submit it how? Submit it where? It's obvious you know nothing about this.

Each one of those protocols works totally different. Different ports, different messages to the server, different ways of contacting the server.

And it's not a text field either. It gets broken up into multiple pieces and each piece is used in a different part of the conversation with the server. And on top of that you need to understand the format to even figure out which server to talk to.

You're talking about the address bar, probably because this issue came up big last time with regard to Google Chrome.

They're talking about input fields in forms in the contents of the page.

So, you both know what you're talking about, you just don't know what they are talking about :)

I hate to be nitpicking but the protocol, while related to the port is still a separate thing. For example, using a url of the type ftp:// is much more than just switching to port 23, even worse a url of the type file:// is not bound to a port as far as I know. Switching protocols mean the actual exhange is completely different.

You can actually use the http protocol on ports other than 80 and its actually commonly done on local development servers where anything like 8080, 8000, 8090 or many others are frquently used. In such a case the url would be something like http://myserver.com:8080/blabla where 8080 would be the port. The confusion might arise because protocols have a default port associated with them. Sorry for the explanation of something thats probably waaaay too simple for most of the readers but that comment was just so wrong for me.

Yep, you're absolutely right. I was making overly broad strokes.

Reply on news.ycombinator.com