On Thu, 29 Aug 2002, Bill Barker wrote: > > So: getServerPort() should return the same as the CGI variable SERVER_PORT > > ( which returns the server port, not the host header ! ), meaning the > > value of the part after : in the Host header. > > > > I didn't know that the servlet spec can define new meanings for the > > CGI spec. > > > > FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync > here. If I actually thought that any members of the JCP were subscribed to > this list, I'd think to ask for clarification before 2.4 went final. :)
Nah... As long as they're returning the port from the host header - I don't want any new clarification :-) Actually, it is right about the server port, since the CGI says: "The port number to which the request was sent." But not for the server name: "The server's hostname, DNS alias, or IP address as it would appear in self-referencing URLs. " And the port can be interpreted easily to mean the Host header. Except that apparently nobody implements it this way. Sometimes it is better to provide all informations about the request - the port it was received on and the host header. If you return the info from the host header in both getServerPort and getHeader(), the port info is lost. For getServerName() - the CGI interpretation is more 'the canonical name'. If I access http://10.0.0.1, the Host will include the IP but SERVER_NAME will be the canonical name. But now that the servlet spec finally 'clarified' the CGI spec, we can wait for IIS and Apache to fix their implementation and be compliant with the CGI spec at least :-) Costin > > > Costin > > > > > > > <spec-quote version="2.4" section="14.2.16"> > > > getServerName() > > > public java.lang.String getServerName() > > > Returns the host name of the server to which the request was sent. For > HTTP > > > servlets, same as the value of the CGI variable SERVER_NAME, meaning the > > > value of the part before ":" in the Host header, if any, or the resolved > > > server > > > name, or the server IP address. > > > Returns: a String containing the name of the server > > > > > > getServerPort() > > > public int getServerPort() > > > Returns the port number to which the request was sent. For HTTP > servlets, > > > same as the value of the CGI variable SERVER_PORT, meaning the value of > the > > > part after ":" in the Host header, if any, or the server port where the > > > client > > > connection was accepted on. > > > Returns: an integer specifying the port number > > > </spec-quote> > > > > > > > > > > > Note that a load balancer or proxy is required ( AFAIK ) to insert > > > > Host: headers if none is present. > > > > > > > > Costin > > > > > > > > On 29 Aug 2002, Bojan Smojver wrote: > > > > > > > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote: > > > > > > > > > > > The question in 12052 is whether Apache should use the socket port > (as > > > it > > > > > > does now), or the port in the Host header. When this came up with > the > > > > > > Coyote/Http11 connector, the decision was that the Host header was > the > > > > > > correct one. I'd have to say that the bug is valid. > > > > > > > > > > This is what the API (2.2) docs say about the getServerPort(): > > > > > > > > > > ---------------- > > > > > Returns the port number on which this request was received. For HTTP > > > > > servlets, same as the value of the CGI variable SERVER_PORT. > > > > > ---------------- > > > > > > > > > > This in itself could be contradicting, but I think that in the case > of > > > > > Apache it is pretty straightforward. > > > > > > > > > > This is what Apache 2.0 does to populate the variable SERVER_PORT: > > > > > > > > > > ---------------- > > > > > apr_table_addn(e, "SERVER_PORT", > > > > > apr_psprintf(r->pool, "%u", > ap_get_server_port(r))); > > > > > ---------------- > > > > > > > > > > And this is the ap_get_server_port(): > > > > > > > > > > ---------------- > > > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r) > > > > > { > > > > > apr_port_t port; > > > > > core_dir_config *d = > > > > > (core_dir_config *)ap_get_module_config(r->per_dir_config, > > > > > &core_module); > > > > > > > > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF > > > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) { > > > > > > > > > > /* With UseCanonicalName off Apache will form > self-referential > > > > > * URLs using the hostname and port supplied by the client > if > > > > > * any are supplied (otherwise it will use the canonical > name). > > > > > */ > > > > > port = r->parsed_uri.port ? r->parsed_uri.port : > > > > > r->server->port ? r->server->port : > > > > > ap_default_port(r); > > > > > } > > > > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */ > > > > > > > > > > /* With UseCanonicalName on (and in all versions prior to > 1.3) > > > > > * Apache will use the hostname and port specified in the > > > > > * ServerName directive to construct a canonical name for > the > > > > > * server. (If no port was specified in the ServerName > > > > > * directive, Apache uses the port supplied by the client if > > > > > * any is supplied, and finally the default port for the > > > > > protocol > > > > > * used. > > > > > */ > > > > > port = r->server->port ? r->server->port : > > > > > r->connection->local_addr->port ? > > > > > r->connection->local_addr->port > > > > > ap_default_port(r); > > > > > } > > > > > > > > > > /* default */ > > > > > return port; > > > > > } > > > > > ---------------- > > > > > > > > > > This doesn't seem like coming from headers, but rather from URL or > as > > > > > indicated by the server itself. What do you think? > > > > > > > > > > Bojan > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
