Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 41904 invoked by uid 500); 29 Nov 2001 18:10:38 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 41893 invoked from network); 29 Nov 2001 18:10:38 -0000 Message-ID: <3C067A22.1020601@feld.cvut.cz> Date: Thu, 29 Nov 2001 19:10:42 +0100 From: Pavel Novy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: cs, en MIME-Version: 1.0 To: dev@httpd.apache.org, bnicholes@novell.com Subject: Re: [PATCH] apache-1.3/src/os/netware/os.c References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Brad, I've tested my patch on NW5.1 SP3+ box with the latest (Beta) patches installed (011022n5 => wsock4f, ...), not running other versions/configurations of NetWare such as NW6, so I can't test it here. I'm not absolutely sure if WSAIoctl(..., SO_SSL_GET_FLAGS,...) is 100% okay. I have no documentation, but I am wondering that zero is returned in lpcbBytesReturned (NULL pointer passed in my patch)... Anyway, value returned by this call in lpvOutBuffer seems to be correct (at least on my server). Additionally to this fix, I am pretty sure that we need more complex ap_is_default_port()/ap_default_port() macro/function. I think that redirection from "https://my_site/location" to "https://my_site:443/location/" is inaccurate (Apache on Linux with mod_ssl doesn't work this way). Port 443 should be considered as default for https scheme. I am also experiencing another issue - if accessing server from our local domain and omitting a domain name in the URL: "http(s)://my_server_without_a_domain_name/location" -> "http(s)://my_server_domain_name/location/" I can't understand why "Location" returned in redirection response (code 301) is not constructed from incoming URI (a trailing slash added), but from (virtual) server's configuration parameters. This is not NetWare specific behaviour and mod_dir (and so on) is responsible for this. However, I'm not too familiar with W3C specification... Regards, Pavel Brad Nicholes wrote: > Pavel, > Your patch looks good. It looks like a much cleaner solution. > What version of Winsock have you tested this patch with? Did you try it > on NW6? As soon as I get some time to implement it and test it myself, > I will get it checked in. > > thanks, > Brad > > > >>>>novy@feld.cvut.cz Wednesday, November 28, 2001 7:50:57 AM >>> >>>> > Hi, > attached patch to fix invalid redirections from > "https://some_site/some_location" to > "http://some_site/some_location/". > > Pavel > >