Project

General

Profile

Bug #1253

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

Added by Anonymous about 12 years ago. Updated about 3 years ago.

Status:
Obsolete
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:
Yes

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

History

#1

Updated by Anonymous about 12 years ago

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

#2

Updated by Anonymous about 12 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

#3

Updated by Anonymous about 12 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

#4

Updated by Anonymous about 12 years ago

i have the same problem with underlines..

-- flycker

#5

Updated by jrabbit about 12 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.

#6

Updated by Anonymous about 12 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

#7

Updated by Anonymous almost 12 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

#8

Updated by Anonymous almost 12 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)) {
#9

Updated by Elfe almost 10 years ago

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

#10

Updated by afinlr almost 10 years ago

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

#11

Updated by gstrauss about 3 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.

#12

Updated by gstrauss about 3 years ago

  • Status changed from New to Obsolete

Also available in: Atom