[users@httpd] 200 OK for a network error?

[Nozomi Anzai]

Hi,

I have a question about HTTP status codes.

- I use Apache 2.2.15 + mod_proxy_ajp + Tomcat 6.0.35.
  - Apache's Timeout is 90 sec, and Tomcat AJP connector's
connectionTimeout is 1 (10 sec).
  - Apache's keepAlive is off.

- While uploading a large-sized file and waiting the resoponse, I switched
  off network of the client machine. 

- The Tomcat returned a status code which depended on the application (500
  internal server error, 200 OK and so on), but Apache always wrote 200 OK
  in its access log.

I'm wondering if it is by design or not that Apache returns 200 OK in such
network error. I don't expect that Apache has to return Tomcat's status
codes, but expect a kind of 50x error.

Any ideas?



The log messages about this are as follows:


[12:00:26] A user starts file uploading.


==> httpd-2.2.15/logs/error_log <==
[Tue Jul 01 12:00:26 2014] [debug] mod_proxy_ajp.c(45): proxy: AJP: 
canonicalising URL //localhost:8009/upload/ultest
:
[Tue Jul 01 12:00:26 2014] [debug] mod_proxy_ajp.c(270): proxy: data to read 
(max 8186 at 4)
[Tue Jul 01 12:00:26 2014] [debug] mod_proxy_ajp.c(285): proxy: got 952 bytes 
of data


[12:00:30] A user disconnects the client's network.


(There are no log messages about this.)


[12:00:50] Tomcat regognizes the timeout. (20 sec after disconnecting)


==> tomcat-6.0.35/logs/catalina.out <==
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:Processing 
of multipart/form-data request failed. Read timed out
:
Caused by: java.net.SocketTimeoutException: Read timed out
:

==> tomcat-6.0.35/logs/localhost.2014-07-01.log <==
Jul 01, 2014 12:00:50 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet uploadtest threw exception
javax.servlet.ServletException: FOR DEBUG servlet
:

==> tomcat-6.0.35/logs/localhost_access_log.2014-07-01.txt <==
133.137.177.172 - - [01/Jul/2014:12:00:50 +0900] "POST /upload/ultest HTTP/1.1" 
500 1362 23396


[12:02:00] Apache recognizes the timeout. (90 sec after disconnecting)


==> httpd-2.2.15/logs/error_log <==
[Tue Jul 01 12:02:00 2014] [debug] mod_proxy_ajp.c(379): (70007)The timeout 
specified has expired: ap_get_brigade failed
[Tue Jul 01 12:02:00 2014] [debug] mod_proxy_ajp.c(545): proxy: Processing of 
request failed backend: 0, output: 1, data_sent: 0
[Tue Jul 01 12:02:00 2014] [debug] proxy_util.c(2029): proxy: AJP: has released 
connection for (localhost)


[12:03:30] Apache recognizes the timeout. (180 sec after disconnecting)


==> httpd-2.2.15/logs/access_log <==
133.137.177.172 - - [01/Jul/2014:12:00:26 +0900] "POST /upload/ultest HTTP/1.1" 
200 - 183547381 -




Regards,

-- 
Nozomi Anzai

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Problem with Content-Type recognition

[Michael Felt]

I did not figure out how to get extra info from the "maintainer" and
"debug" enabled version, and it was not as stable (may need to also rebuild
the php module against the "debug" version. I hoped syslog and .debug level
would be very verbose.

So, call me "anything you like", but I am not coming up with the right
combination of directives to get httpd to ignore the .php in the filename
(e.g., removeEncoding had no effect).

What directive should I be using instead?

Many thanks for assistance!

Michael


On Mon, Jun 23, 2014 at 2:51 PM, Michael Felt  wrote:

> I have recompiled httpd-2.2.27 with --enable-maintainer-mode and
> --enable--debugger-mode, and set, to be sure, optimization to -O0
>
> Some help with what needs to be done to get more debug info into the logs
> is appreciated.
>
> (Note: going on a short vacation, so I might not respond again real soon).
>
>
> On Mon, Jun 23, 2014 at 10:48 AM, Michael Felt  wrote:
>
>> Good Idea, and I was hoping that using
>>
>> RemoveEncoding .php
>>
>> was doing that.
>>
>> As this is a vhost, and other vhosts are using php I do not see removing
>> PHP from the server as a solution. So, RemoveEncoding may be the wrong
>> solution. (I was glad I even figured out that the embedded .php. in the
>> filename is what was triggering this?)
>>
>> Should I "change" the encoding - will that override the effect you
>> describe?
>>
>> I tried experimenting with this: still not getting the effect I am
>> looking for. I am assuming I am using the wrong directive. (I removed the
>> RemoveEncoding because I changed the Type - and it did not seem to be doing
>> anything anyway).
>>
>> 
>> DefaultType application/octet-stream
>> AddType application/octet-stream .php
>>
>> 
>> #   RemoveEncoding .php
>>
>> ForceType application/octet-stream
>> 
>> Options Indexes FollowSymLinks
>> IndexOptions FancyIndexing Namewidth=* FoldersFirst
>> SuppressDescription
>> IndexOrderDefault Descending Date
>> AllowOverride None
>> Order allow,deny
>> Allow from all
>> 
>>
>>
>>
>> On Sun, Jun 22, 2014 at 11:45 PM, Nick Kew  wrote:
>>
>>> On Sat, 21 Jun 2014 16:45:10 +0200
>>> Michael Felt  wrote:
>>>
>>> > I have tried, in a vhost area, to set the DefaultType to
>>> > application/octet-stream, and I have tried to add a Type for .I
>>> (capital i)
>>> > endings. However, httpd-2.2.27 seems to be preferring the .php. in the
>>> > filename rather than the .I at the end of the file. When I link the
>>> file to
>>> > that it has the name *.php5.* then the ContentType: is as expected.
>>>
>>> If you have PHP handling .php requests, then PHP sets the Content-Type
>>> (and other) headers, overriding your config.
>>>
>>> Turn off PHP (in the scope of the URL in question) if you want
>>> to use Apache configuration to control content-type.
>>>
>>>
>>> --
>>> Nick Kew
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>>
>>
>

Re: [users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Rose, John B]

Thanks

We will try that

From: Jeff Trawick mailto:traw...@gmail.com>>
Reply-To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Date: Monday, June 30, 2014 3:36 PM
To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Subject: Re: [users@httpd] mod_macro cause delay before virtual host sites 
available after graceful?

On Mon, Jun 30, 2014 at 2:54 PM, Rose, John B 
mailto:jbr...@utk.edu>> wrote:
When we do a graceful restart there is a delay of 30-40 seconds each time 
accessing each of our virtual hosts.

Accessing the server itself has no delay.

We noticed this after we implemented mod_macro, but it affects all virtual 
hosts, not just the mod_macro sites.

This had not been an issue previously, for several months.

Any ideas?

Slow DNS lookup perhaps?

Run strace with timestamps against the httpd parent process before initiating 
graceful restart, and see if you can locate the delays between recognizable 
processing.




--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/

Re: [users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Rose, John B]

To clarify, the delay is only initially after the graceful. Once they load, 
things are fine from then on.

Also, we do notice  a much larger number of "internal dummy connection" entries 
in the access_log immediately after each graceful recently as compared with the 
previous  months.

From: Rich Bowen mailto:rbo...@rcbowen.com>>
Reply-To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Date: Monday, June 30, 2014 3:22 PM
To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Subject: Re: [users@httpd] mod_macro cause delay before virtual host sites 
available after graceful?


On 06/30/2014 02:54 PM, Rose, John B wrote:
When we do a graceful restart there is a delay of 30-40 seconds each time 
accessing each of our virtual hosts.

Accessing the server itself has no delay.

We noticed this after we implemented mod_macro, but it affects all virtual 
hosts, not just the mod_macro sites.

This had not been an issue previously, for several months.

Any ideas?

How many macros do you have defined? 40 seconds seems *really* long unless you 
have a HUGE number of macros that it has to chunk through.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: [users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Rose, John B]

We have one virtual host defined via mod_macro method.

The others have their own .conf

From: Rich Bowen mailto:rbo...@rcbowen.com>>
Reply-To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Date: Monday, June 30, 2014 3:22 PM
To: "users@httpd.apache.org" 
mailto:users@httpd.apache.org>>
Subject: Re: [users@httpd] mod_macro cause delay before virtual host sites 
available after graceful?


On 06/30/2014 02:54 PM, Rose, John B wrote:
When we do a graceful restart there is a delay of 30-40 seconds each time 
accessing each of our virtual hosts.

Accessing the server itself has no delay.

We noticed this after we implemented mod_macro, but it affects all virtual 
hosts, not just the mod_macro sites.

This had not been an issue previously, for several months.

Any ideas?

How many macros do you have defined? 40 seconds seems *really* long unless you 
have a HUGE number of macros that it has to chunk through.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: [users@httpd] Mailman CGI scripts served instead of executed

[Miles Fidelman]

Remco Poelstra wrote:

Op 30 jun. 2014, om 20:23 heeft Miles Fidelman  het 
volgende geschreven:


Remco Poelstra wrote:

Op 30 jun. 2014, om 19:56 heeft Miles Fidelman mailto:mfidel...@meetinghouse.net>> het volgende geschreven:


Remco Poelstra wrote:

Hi,

I'm migrating a mailman server to a newer machine. The new machine runs apache 
2.4. My problem is that the mailman cgi scripts are served instead of being 
executed.
My configuration looks like the following:

ServerName lists.xxx
DocumentRoot /home/www/lists.xxx
ScriptAlias /mailman/ /var/www/w-lists/

SuexecUserGroup w-lists w-lists


Require all granted
AddHandler fcgid-script .php
Options +ExecCGI
FCGIWrapper /var/www/w-lists/php5-cgi .php



In the document root there is a php script that redirects to /mailman/listinfo. 
The php5-cgi wrapper is in /var/www/w-lists. The php script gets properly 
executed, but the mailman scripts (also in /var/www/w-lists) are served 
directly instead of being executed.

I've tried adding a "SetHandler fcgid-script" on the /var/www/w-lists 
directory, but that gives me a server error.
Basically the same configuration works nicely on the old machine (running 
apache 2.2).


Silly question: are the any chance that the scripts aren't executable (chmod 
+x)?  Permissions can screw you - they're the first thing I always check.

They are all -rwxr-xr-x and w-lists:w-lists, so I believe that's OK.


hmm

Just to be clear - you're saying that SOME php scripts in /var/www/w-lists 
execute properly, and others (the mailman scripts) do not?

If that's the case, you might want to really carefully examine what's different 
between the scripts that run and the ones that download - things like perhaps 
.php vs. php5 suffixes, and such.

You might also want to look around for extraneous .htaccess files that have 
conflicting information than what's in your config file.

I guess you should also see if the .php setup is different on your new machine.

To be more clear, ONLY the php script gets executed. The others are ELF 
binaries and have no extension. So it's difficult to compare why the php script 
works and the others do not. Maybe the difference is that the php script itself 
is in the document root and only the wrapper is in the scripts folder, while 
the other scripts are called directly.
There are no errors or warnings generated, apache just happily hands over the 
binary file.



Now that's a whole other kettle of fish:
- So the AddHandler fcgid-script .php line is working properly, but,
- ScriptAlias /mailman/ /var/www/w-lists/  is not

Maybe try upping your log level and looking at what happens when you try 
to access one of the scripts - it might give you some clues.


And.. I think I just figured out what's happening: There's no handler 
defined for files that don't have a suffix.


You might try replacing the AddHandler line with "SetHandler 
fcgid-script" - which should make EVERYTHING in that directory executable.


On the other hand, if some files in that directory are NOT executable, 
then maybe do this instead"

- add a .fcgi extension to each of your binary scripts
- change the AddHandler fcgid-script .php to "AddHandler fcgid-script 
.php .fcgi"


Cheers,

Miles Fidelman

--
In theory, there is no difference between theory and practice. In 
practice, there is.  Yogi Berra


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Jeff Trawick]

On Mon, Jun 30, 2014 at 2:54 PM, Rose, John B  wrote:

>  When we do a graceful restart there is a delay of 30-40 seconds each
> time accessing each of our virtual hosts.
>
>  Accessing the server itself has no delay.
>
>  We noticed this after we implemented mod_macro, but it affects all
> virtual hosts, not just the mod_macro sites.
>
>  This had not been an issue previously, for several months.
>
>  Any ideas?
>

Slow DNS lookup perhaps?

Run strace with timestamps against the httpd parent process before
initiating graceful restart, and see if you can locate the delays between
recognizable processing.




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/

Re: [users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Rich Bowen]

On 06/30/2014 02:54 PM, Rose, John B wrote:
When we do a graceful restart there is a delay of 30-40 seconds each 
time accessing each of our virtual hosts.


Accessing the server itself has no delay.

We noticed this after we implemented mod_macro, but it affects all 
virtual hosts, not just the mod_macro sites.


This had not been an issue previously, for several months.

Any ideas?


How many macros do you have defined? 40 seconds seems *really* long 
unless you have a HUGE number of macros that it has to chunk through.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

[users@httpd] mod_macro cause delay before virtual host sites available after graceful?

[Rose, John B]

When we do a graceful restart there is a delay of 30-40 seconds each time 
accessing each of our virtual hosts.

Accessing the server itself has no delay.

We noticed this after we implemented mod_macro, but it affects all virtual 
hosts, not just the mod_macro sites.

This had not been an issue previously, for several months.

Any ideas?

Re: [users@httpd] Mailman CGI scripts served instead of executed

[Remco Poelstra]

Op 30 jun. 2014, om 20:23 heeft Miles Fidelman  het 
volgende geschreven:

> Remco Poelstra wrote:
>> Op 30 jun. 2014, om 19:56 heeft Miles Fidelman > > het volgende geschreven:
>> 
>>> Remco Poelstra wrote:
 Hi,
 
 I'm migrating a mailman server to a newer machine. The new machine runs 
 apache 2.4. My problem is that the mailman cgi scripts are served instead 
 of being executed.
 My configuration looks like the following:
 
 ServerName lists.xxx
 DocumentRoot /home/www/lists.xxx
 ScriptAlias /mailman/ /var/www/w-lists/
 
 SuexecUserGroup w-lists w-lists
 
 
 Require all granted
 AddHandler fcgid-script .php
 Options +ExecCGI
 FCGIWrapper /var/www/w-lists/php5-cgi .php
 
 
 
 In the document root there is a php script that redirects to 
 /mailman/listinfo. The php5-cgi wrapper is in /var/www/w-lists. The php 
 script gets properly executed, but the mailman scripts (also in 
 /var/www/w-lists) are served directly instead of being executed.
 
 I've tried adding a "SetHandler fcgid-script" on the /var/www/w-lists 
 directory, but that gives me a server error.
 Basically the same configuration works nicely on the old machine (running 
 apache 2.2).
 
>>> 
>>> Silly question: are the any chance that the scripts aren't executable 
>>> (chmod +x)?  Permissions can screw you - they're the first thing I always 
>>> check.
>> 
>> They are all -rwxr-xr-x and w-lists:w-lists, so I believe that's OK.
>> 
> hmm
> 
> Just to be clear - you're saying that SOME php scripts in /var/www/w-lists 
> execute properly, and others (the mailman scripts) do not?
> 
> If that's the case, you might want to really carefully examine what's 
> different between the scripts that run and the ones that download - things 
> like perhaps .php vs. php5 suffixes, and such.
> 
> You might also want to look around for extraneous .htaccess files that have 
> conflicting information than what's in your config file.
> 
> I guess you should also see if the .php setup is different on your new 
> machine.

To be more clear, ONLY the php script gets executed. The others are ELF 
binaries and have no extension. So it's difficult to compare why the php script 
works and the others do not. Maybe the difference is that the php script itself 
is in the document root and only the wrapper is in the scripts folder, while 
the other scripts are called directly.
There are no errors or warnings generated, apache just happily hands over the 
binary file.

Remco


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Mailman CGI scripts served instead of executed

[Miles Fidelman]

Remco Poelstra wrote:
Op 30 jun. 2014, om 19:56 heeft Miles Fidelman 
mailto:mfidel...@meetinghouse.net>> het 
volgende geschreven:



Remco Poelstra wrote:

Hi,

I'm migrating a mailman server to a newer machine. The new machine 
runs apache 2.4. My problem is that the mailman cgi scripts are 
served instead of being executed.

My configuration looks like the following:

ServerName lists.xxx
DocumentRoot /home/www/lists.xxx
ScriptAlias /mailman/ /var/www/w-lists/

SuexecUserGroup w-lists w-lists


Require all granted
AddHandler fcgid-script .php
Options +ExecCGI
FCGIWrapper /var/www/w-lists/php5-cgi .php



In the document root there is a php script that redirects to 
/mailman/listinfo. The php5-cgi wrapper is in /var/www/w-lists. The 
php script gets properly executed, but the mailman scripts (also in 
/var/www/w-lists) are served directly instead of being executed.


I've tried adding a "SetHandler fcgid-script" on the 
/var/www/w-lists directory, but that gives me a server error.
Basically the same configuration works nicely on the old machine 
(running apache 2.2).




Silly question: are the any chance that the scripts aren't executable 
(chmod +x)?  Permissions can screw you - they're the first thing I 
always check.


They are all -rwxr-xr-x and w-lists:w-lists, so I believe that's OK.


hmm

Just to be clear - you're saying that SOME php scripts in 
/var/www/w-lists execute properly, and others (the mailman scripts) do not?


If that's the case, you might want to really carefully examine what's 
different between the scripts that run and the ones that download - 
things like perhaps .php vs. php5 suffixes, and such.


You might also want to look around for extraneous .htaccess files that 
have conflicting information than what's in your config file.


I guess you should also see if the .php setup is different on your new 
machine.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Mailman CGI scripts served instead of executed

[Remco Poelstra]

Op 30 jun. 2014, om 19:56 heeft Miles Fidelman  het 
volgende geschreven:

> Remco Poelstra wrote:
>> Hi,
>> 
>> I'm migrating a mailman server to a newer machine. The new machine runs 
>> apache 2.4. My problem is that the mailman cgi scripts are served instead of 
>> being executed.
>> My configuration looks like the following:
>> 
>>  ServerName lists.xxx
>>  DocumentRoot /home/www/lists.xxx
>>  ScriptAlias /mailman/ /var/www/w-lists/
>> 
>>  SuexecUserGroup w-lists w-lists
>> 
>>  
>>  Require all granted
>>  AddHandler fcgid-script .php
>>  Options +ExecCGI
>>  FCGIWrapper /var/www/w-lists/php5-cgi .php
>>  
>> 
>> 
>> In the document root there is a php script that redirects to 
>> /mailman/listinfo. The php5-cgi wrapper is in /var/www/w-lists. The php 
>> script gets properly executed, but the mailman scripts (also in 
>> /var/www/w-lists) are served directly instead of being executed.
>> 
>> I've tried adding a "SetHandler fcgid-script" on the /var/www/w-lists 
>> directory, but that gives me a server error.
>> Basically the same configuration works nicely on the old machine (running 
>> apache 2.2).
>> 
> 
> Silly question: are the any chance that the scripts aren't executable (chmod 
> +x)?  Permissions can screw you - they're the first thing I always check.

They are all -rwxr-xr-x and w-lists:w-lists, so I believe that's OK.

Remco

Re: [users@httpd] Mailman CGI scripts served instead of executed

[Miles Fidelman]

Remco Poelstra wrote:

Hi,

I'm migrating a mailman server to a newer machine. The new machine runs apache 
2.4. My problem is that the mailman cgi scripts are served instead of being 
executed.
My configuration looks like the following:

ServerName lists.xxx
DocumentRoot /home/www/lists.xxx
ScriptAlias /mailman/ /var/www/w-lists/

SuexecUserGroup w-lists w-lists


Require all granted
AddHandler fcgid-script .php
Options +ExecCGI
FCGIWrapper /var/www/w-lists/php5-cgi .php



In the document root there is a php script that redirects to /mailman/listinfo. 
The php5-cgi wrapper is in /var/www/w-lists. The php script gets properly 
executed, but the mailman scripts (also in /var/www/w-lists) are served 
directly instead of being executed.

I've tried adding a "SetHandler fcgid-script" on the /var/www/w-lists 
directory, but that gives me a server error.
Basically the same configuration works nicely on the old machine (running 
apache 2.2).



Silly question: are the any chance that the scripts aren't executable 
(chmod +x)?  Permissions can screw you - they're the first thing I 
always check.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Mailman CGI scripts served instead of executed

[Remco Poelstra]

Hi,

I'm migrating a mailman server to a newer machine. The new machine runs apache 
2.4. My problem is that the mailman cgi scripts are served instead of being 
executed.
My configuration looks like the following:

ServerName lists.xxx
DocumentRoot /home/www/lists.xxx
ScriptAlias /mailman/ /var/www/w-lists/

SuexecUserGroup w-lists w-lists


Require all granted
AddHandler fcgid-script .php
Options +ExecCGI
FCGIWrapper /var/www/w-lists/php5-cgi .php



In the document root there is a php script that redirects to /mailman/listinfo. 
The php5-cgi wrapper is in /var/www/w-lists. The php script gets properly 
executed, but the mailman scripts (also in /var/www/w-lists) are served 
directly instead of being executed.

I've tried adding a "SetHandler fcgid-script" on the /var/www/w-lists 
directory, but that gives me a server error.
Basically the same configuration works nicely on the old machine (running 
apache 2.2).

How can I solve this problem?

Thanks in advance.

Kind regards,

Remco Poelstra
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Discussion about possible new feature for Apache HTTP Server

[D'Arcy J.M. Cain]

On Mon, 30 Jun 2014 13:23:37 +0100
Gulkamal Singh  wrote:
> 1) A browser that has a simple interface from where I can map a key
> to a url.  When I make a request to my admin URL, it sends this key
> in the header, get or post.
> 2) A server which shows a 404 unless the key is present in the
> header, get or post.
> 
> This is fairly a simple feature and I feel that if browsers and
> servers implement this, it could become popular.  Could people please
> give me thoughts on this, if there might be benefits to this, and if
> it would be possible for apache http server to implement this?

I think you are being way too complicated.  Just put your admin page at
something like www.mysite.com/h7Swu72fFqdk and add that to your
bookmarks.  No one is going to accidentally type that in.  In fact, I
often use that in lieu of actual password protection when convenience
is more important than high security.

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Discussion about possible new feature for Apache HTTP Server

[Jeroen Van den Horn]

I'm sure that when you fiddle a bit with some RewriteCond's and
RewriteRules you can accomplish what you want out-of-the-box.

J


On Mon, Jun 30, 2014 at 2:23 PM, Gulkamal Singh 
wrote:

> Lets say that I have a domain hosting a public facing website (
> www.mywebsite.com).  Now lets say that -
>
> 1) Security is not a big thing.
> 2) To save money, I want to host the admin interface on the same domain (
> www.mywebsite.com/admin).
> 3) The admin interface requires login but never the less I do not want the
> public to be even aware of the location of the admin interface.
> 4) But there is a chance that someone might type in
> www.mywebsite.com/admin by guessing and discover that there is an admin
> user interface there.
> 5) I dont want to use complicated IP blocking to block access to the admin
> interface - I want to be able to login from any machine.  I also dont want
> to go down the expensive certificate route.
>
> In this case, the following will be useful -
>
> 1) A browser that has a simple interface from where I can map a key to a
> url.  When I make a request to my admin URL, it sends this key in the
> header, get or post.
> 2) A server which shows a 404 unless the key is present in the header, get
> or post.
>
> This is fairly a simple feature and I feel that if browsers and servers
> implement this, it could become popular.  Could people please give me
> thoughts on this, if there might be benefits to this, and if it would be
> possible for apache http server to implement this?
>

[users@httpd] Discussion about possible new feature for Apache HTTP Server

[Gulkamal Singh]

Lets say that I have a domain hosting a public facing website (
www.mywebsite.com).  Now lets say that -

1) Security is not a big thing.
2) To save money, I want to host the admin interface on the same domain (
www.mywebsite.com/admin).
3) The admin interface requires login but never the less I do not want the
public to be even aware of the location of the admin interface.
4) But there is a chance that someone might type in www.mywebsite.com/admin
by guessing and discover that there is an admin user interface there.
5) I dont want to use complicated IP blocking to block access to the admin
interface - I want to be able to login from any machine.  I also dont want
to go down the expensive certificate route.

In this case, the following will be useful -

1) A browser that has a simple interface from where I can map a key to a
url.  When I make a request to my admin URL, it sends this key in the
header, get or post.
2) A server which shows a 404 unless the key is present in the header, get
or post.

This is fairly a simple feature and I feel that if browsers and servers
implement this, it could become popular.  Could people please give me
thoughts on this, if there might be benefits to this, and if it would be
possible for apache http server to implement this?