Project

General

Profile

Actions

Bug #1253

closed

underline in http address causes a 400 - Bad Request error example http://my_web.com.br

Added by Anonymous over 16 years ago. Updated over 7 years ago.

Status:
Obsolete
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:

Description

underline in http address causes a 400 - Bad Request error example http://my_web.com.br

I have tested this and in apache works fine.

http://www.google.com.br/search?q=site%3Ahipermusicas.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:pt-BR:official&client=firefox-a

-- itamar

Actions #1

Updated by Anonymous over 16 years ago

Underscore is not a valid character in a hostname. See http://tools.ietf.org/html/rfc952.

Actions #2

Updated by Anonymous over 16 years ago

and lighttpd works only with hostname ? the dns accept underscore

take a look on rfc1033

http://www.faqs.org/rfcs/rfc1033.html

"A-Z", "a-z", "0-9", dash and underscore

-- itamar

Actions #3

Updated by Anonymous over 16 years ago

Underscore is not an option. RFC 1033 is wrong about this, and it's only some guideline paper, anyway, so there's no relevance here. I'd say that lighty's response 400 is pretty clean and straight forward.

-- anonymous coward

Actions #4

Updated by Anonymous over 16 years ago

i have the same problem with underlines..

-- flycker

Actions #5

Updated by jrabbit over 16 years ago

What is and isn't valid in DNS is completely irrelevant (almost), as is what is and isn't valid on the Internet - who says a server has to be on the Internet or have its name resolved using DNS?

For lighttpd to satisfy the standards regarding hostnames, the only thing it should comply with is the HTTP specification for the host portion of a URI. The HTTP 1.1 specification references RFC 2396 for this, which defines the host portion of an HTTP URI as complying with section 3 of the DNS specification in RFC 1034, which in turn says letters, numbers and hyphen with no label being more than 63 characters and the entire name being no more than 255 characters. Therefore, by this definition "_" is invalid.

However, RFC 2396 was obseleted in 2005 by RFC 3986 which extends the set of characters that are valid in the host portion of a URI to:


A-Z / a-z / 0-9 / "-" / "." / "_" / "~" / "!" / 
"$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / 
";" / "=" and a "%" followed by two hex digits.

No updates to HTTP have been published since then, and I'm not sure what the rules are - if RFC A references RFC B which is obseleted by RFC C, does that mean applications conforming to RFC A now must comply with RFC C? If so, "_" should be allowed.

From a practical standpoint, lighttpd can run on a local Windows network and URLs can contain Windows hostnames instead of DNS names, so I think it should be supported.

Actions #6

Updated by Anonymous over 16 years ago

'''This is my case:'''

I use willcard dns record to all my subdomains. I have a free forum creating site, and the users can put "_" in theirs forum name, who will be the name of subdomain. (my_forum.mysite.com)
Maybe its my fault to allowed that.. but it's works.
With apache works too.. i thinking on change to "-", but i have a loot of subdomains in this case and more then 20 billions pageviews per month. It will be a loot of trouble to change..
Its a practical case, and i cannot use lighty because this.. falling back to apache.

Examples:

http:// gg_lunaticos dot queroumforum dot com
http:// escorts_pt dot queroumforum dot com
http:// dj_victor_x_forum dot iwannaforum dot com

Thanks and sorry for bad english.

-- tiagofischer

Actions #7

Updated by Anonymous over 16 years ago

Can you show me where i need to change this in the source?
I wondering to change this before compile.. then i can use!

Thanks

-- flycker

Actions #8

Updated by Anonymous over 16 years ago

It's not the best solution.. but its work to fix my problem:

Examples:

http:// gg_lunaticos .queroumforum.com 
http:// _teste .queroumforum.com 
http:// teste2_ .queroumforum.com 
http:// +teste_++teste_+teste__ .queroumforum.com [[[BR]]]

Diff:

106c106 
<                                               if (!light_isalpha(host->ptr[i+1])) { 
--- 
>                                               if (!light_isalpha(host->ptr[i+1]) && '_' != host->ptr[i+1]) { 
128c128 
<                               if (!light_isalpha(c)) { 
--- 
>                               if (!light_isalpha(c) && '_' != c) { 
133c133 
<                               if (c != '-' && !light_isalnum(c)) { 
--- 
>                               if (c != '_' && c != '-' && !light_isalnum(c)) { 
171c171 
<                                       if (!light_isalnum(c)) { 
--- 
>                                       if (!light_isalnum(c) && c != '_') { 
176c176 
<                                       if (c != '-' && !light_isalnum(c)) { 
--- 
>                                       if (c != '_' && c != '-' && !light_isalnum(c)) {
Actions #9

Updated by Elfe over 14 years ago

any chance to get this fix into a 1.4.x release?

Actions #10

Updated by afinlr over 14 years ago

I'd like to put in my request for this fix too please.

Actions #11

Updated by gstrauss over 7 years ago

  • Description updated (diff)
  • Assignee deleted (jan)
  • Priority changed from High to Normal
  • Missing in 1.5.x set to Yes

lighttpd 1.4.40 provides config option server.http-parseopt-host-strict = "disable" to allow this.

Actions #12

Updated by gstrauss over 7 years ago

  • Status changed from New to Obsolete
Actions

Also available in: Atom