try:
apxs -o mod_jk.so -DSOLARIS -lposix4 -I../jk -I/usr/java/include
-I/usr/java/include/solaris -c *.c ../jk/*.c
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=286
*** shadow/286 Fri Mar 9 21:21:33 2001
--- shadow/286.tmp.13587Fri Mar 9 21:21:33
Title: what is the deal with tomcat 4 and web server connectors??
i want to move from tomcat 3.x to tomcat 4. i absolutely must be able to use tomcat 4 with netscape/iplanet and microsoft (iis) web servers. as near as i can tell, the only connector that will be available in the foreseeable
Unless everyone's in a hurry to port mod_jk on TC 4 ASAP, I suggest waiting
a bit. I'll be spending time on a new connector architecture for TC 4
which will actually be very similar to the one in TC 3.3 (except hopefully
even cleaner and simpler). That should make porting mod_jk much easier
for those who are interested...
updated code for ajp13 connector for tomcat 4. this version more or
less works, but needs some major cleanup/refactoring.
i ended up copying a bunch of code out of some files in the http
connector package, and the Http*Base classes out of the connector
package.
Keep up the good works. I'll test it against my mod_jk.
Which version of Tomcat 4.0 must I use, TC 4.0B3 ?
i'm using tc 4.0b3.
as i keep updating my code, what is the best way to share it? keep
posting updates to this list?
-kevin.
why does the http/1.1 connector in tomcat 4 not set a connection:
keep-alive header? doesn't it need to?
thanks, -kevin
can you provide some more info? like, tomcat version, os, etc.? i want
to say i saw something like this a long time ago, and it was a problem
in mod_jk somewhere. but trying to remember past last week is difficult
at best :)
Ben Sifuentes wrote:
Can somebody take the time to help me figure
i'm not the expert on these things, but i'll try to answer your
questions as best i can. i'm sure if i say something that is blatantly
wrong, i will be corrected ;) the information here is pretty much what
i've figured out for myself using tomcat over the last year or so...
I am using
and recreate this in a small
example that i can post.
-kevin.
kevin seguin wrote:
i have a servlet that creates a thread in it's service method. this
thread basically does a bunch of initialization stuff.
when i add a load-on-startup element for this servlet in web.xml, it
reports
With the current code it will fail indeed.
any reason(s) why? will this be fixed?
thanks, -kevin.
going to try and recreate this in a small
example that i can post.
-kevin.
kevin seguin wrote:
i have a servlet that creates a thread in it's service method. this
thread basically does a bunch of initialization stuff.
when i add a load-on-startup element for this servlet
so, i guess the essence of this message is, what might be a short-term
plan for having ajp13 support in tomcat 4?
i have done some preliminary work, creating an ajp13 connector for tc 4,
which for the most part works.
long term, i think part of this code will live in
I wouldn't mind seeing the connector used for Jetty or other servlet
containers ( the same as many containers are using jasper ) - code sharing
is allways good.
+100 :)
GOMEZ Henri wrote:
The discussion about jakarta-tomcat-connectors is closed and the CVS
is created (even if I still couldn't access it)
-kevin.
btw, the reason i'm so interested in this because i want to make the
switch from tc3 to tc4, but i *have* to have connector support for
BTW, we'll need to discuss about the Java side - so
optimizations on the lower level would work on any container.
At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent
( i.e. recyclable, low overhead, etc ), and a simple Request object that
can be easily adapted to TC3.3
The whole idea is to avoid expensive operations until they are actually
needed - most servlets don't read all the headers, so there's no need to
create the strings and hash them. ( it's not even needed to convert from
bytes to chars - another expensive operation ).
i'm going to go with
seguin 01/05/10 17:36:37
jakarta-tomcat-connectors/src - New directory
I don't agree with that directory structure.
I think it should be :
[subproject]/src/java
i agree.
+1.
GOMEZ Henri wrote:
I'd like to rename the mod_jk and jk_ stuff to
mod_jtc (jtc_) to let users have at the same
time the actual mod_jk and the in dev mod_jtc.
Are you agree ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD
actually, i think i might prefer something like mod_ajp and ajp_. if
jtc means jakarta-tomcat-connector, that might be a little too generic.
what do you call the next connector protocal?
kevin seguin wrote:
+1.
GOMEZ Henri wrote:
I'd like to rename the mod_jk and jk_ stuff
GOMEZ Henri wrote:
actually, i think i might prefer something like mod_ajp and ajp_. if
jtc means jakarta-tomcat-connector, that might be a little too
generic.
what do you call the next connector protocal?
and ajp = Apache Jakarta Protocol (which not much clear)
so, do you envision
The source is :
jakarta-tomcat-connectors/src/java/
jakarta-tomcat-connectors/src/native/...
i'm fine with that. i believe somebody else did object, though...
don't know if that matters :)
In my idea native is just mod_jtc, which replace mod_jk.
We have only connector projects
as you probably noticed, i checked in my ajp13 connector for tomcat 4.
it's in need of some refactoring (but does work, except for
load-balancing), but i wanted to at least get it checked so others will
have access to it.
there are some (minimal) instructions for using this connector in
Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which is the module I'm
writing right now...
so... iis is next, right ;-)
eventually, i'd like to make use of some of the low-level util classes
like MessageBytes that currently exist in tomcat 3 in
jakarta-tomcat-connectors (jtc). i suppose i could just copy those
classes from the tomcat 3 source to jtc but, well, code duplication is
bad.
there had been some talk of
Pier P. Fumagalli wrote:
kevin seguin at [EMAIL PROTECTED] wrote:
Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which is the module I'm
writing right now...
so... iis is next, right ;-)
Yes, IIS is next, I just need to install Win2K on my only Intel box I have.
It's a very
in the java side of ajp13, it is pretty much assumed that strings are
iso-8859-1 encoded. (i'm not sure how things that deal with
MessageBytes that come out of ajp13 deal with encoding...).
is this a potential problem? i realize that for things like standard
header names this will generally
i just happened to be looking through the RequestUtil.parseParameters()
method, and something struck me as odd. since i don't know the history
here, i figured i'd ask someone who does...
anyway, the method looks something like this:
public static void parseParameters(Map map, String data,
what might be an even more relevant question is why convert the string
to bytes anyways? these bytes just end up in new strings, so why not
perform the parsing logic on chars rather than bytes? seems like
unecessary conversions to/from bytes/strings
-kevin.
kevin seguin wrote:
i just
We use simple byte conversion there because the String which is passed here
(the query portion of the URL) is supposed to only have US-ASCII characters.
it's also used to parse form data, right? can form data have non
US-ASCII characters?
what might be an even more relevant question is why convert the string
to bytes anyways? these bytes just end up in new strings, so why not
perform the parsing logic on chars rather than bytes? seems like
unecessary conversions to/from bytes/strings
Well, there are a number of
it's also used to parse form data, right? can form data have non
US-ASCII characters?
No. Form data uses parseParameters(Map, byte[], String encoding) for that
reason.
ahh... that's what i missed. thanks.
If the thing was memory efficient, the url should still be in byte form at
so, i'm looking at decoupling the Ajp13 java stuff from servlet
container code.
some background... in tomcat 3, the ajp code takes a core tomcat Request
object and adds decoded information from the ajp request into the
Request object. when i ported this code from tomcat 3 to tomcat 4, i
used
So we have 2 cygwin (amy+jon) and 1 msvc (kevin)... I hoped to have more
feedback... I'll start with cygwin (since I can get it for free)
does it really matter much? it should build with both cygwin and msvc,
right? you might just have different makefiles for the two.
-kevin.
[+1] Let's move mod_webapp and all its related stuff in jakarta-connectors.
[ 0] I don't give a damn.
[-1] Keep it where it is because (please explain)
+1
i'm of the opinion that the core parts of connectors should be servlet
container agnostic and separate from any container.
also,
the dilemma is what to pass to the ajp code that accepts requests in the
new world where this code could be used by any servlet container. the
choices as i see them are:
1) a concrete object (say AjpRequest) that takes and stores information
from the request
2) an interface that
However, since I just recently sold management on linux/apache/tomcat as our
next gen platform, and I can put that on my desktop as well, it's not much
skin off my nose if the connectors are suboptimal on NT. g
unfortunately, not all management is as enlightened as yours appears to
be ;)
i didn't see any comments in commit messages that mentioned the problem
you are speaking of. can you find that comment again and send it?
thanks.
DAK wrote:
Here's my first submission! It pertains to Tomcat-3.2.1 and looks to be
the same in 3.2.2.b4
I have some client code that sends a
i didn't see any comments in commit messages that mentioned the problem
you are speaking of. can you find that comment again and send it?
thanks.
DAK wrote:
Here's my first submission! It pertains to Tomcat-3.2.1 and looks to be
the same in 3.2.2.b4
I have some client code that sends a
i actually decided to copy a bunch of low-level utility classes from tc
3 to jtc/util until something like a jakarta-tomcat-commons exists...
GOMEZ Henri wrote:
The problem is not only the Request object, but the whole
infrastructure
needed for efficient communication ( MessageBytes,
Ryan Smith wrote:
I have found a bug and fixed it in the Tomcat NT
service program. How do I submit it? Do you guys take
bug fixes from independent people. I had heard from
several people that they had submitted bug fixes and
you guys told them to f*** off (not necessarily in
those
Ajpv12 does not handle uploads well due to design, so
most of upload bug fixes were never backported from Ajpv13.
The moral is to use only Ajpv13 or higher for uploads.
i've been uploading all different kinds of files (via post data) with
ajp12 for a while, and haven't seen any problems.
+1
GOMEZ Henri wrote:
I would like to propose Jean-Frederic Clere as a new committer.
He make many contribution in jakarta-tomcat, jakarta-tomcat-4.0
and now in jakarta-tomcat-connectors, and we help us with
stuff like autoconf, APR and exotics systems :)
Vote Please
seems like this stuff is completely separate from tomcat... so it seems
like it ought to go somewhere else.
just my $0.02 :)
Pier P. Fumagalli wrote:
I believe we're at a pretty good point right now with the development of the
JSR-096, describing how Daemons are supposed to be working in
i believe i saw a problem similar to this in tomcat 3.2b4. the problem
turned out to be a bug in org.apache.tomcat.util.SimplePool.
i believe this particular problem has been fixed in later versions. if
you have the source, you might want to compare your version of this
class to a more recent
I would like to propose Ryan Bloom as commiter
in Tomcat, and particulary on jakarta-tomcat-connector.
Ryan is one of the dev leader in Apache 2.0 and
contributed many patch for both mod_jk and mod_webapp,
showing us that connectors avoid politics :)
Vote, please
+1
There are documents for using tomcat-4.0 with mod_jk?
Those would be very useful.
The only thing that is Tomcat-4-specific is the Connector
entry, which
is documented in jk/README.txt in the jakarta-tomcat-connectors
repository. All of the configuration files for JK are,
AFAIK,
with the
release distribution.
mod_webapp will stay as the default native connector, as it has better
integration with Tomcat 4.
The Catalina wrapper for JK supports version 1.3, and was
written by Kevin
Seguin. The source code for this module is in
jakarta-tomcat-connectors/jk.
ballot
in ajp_process_callback, here is the block of code that handles sending the
next chunk of data from the webserver to tomcat:
--- snip ---
case JK_AJP13_GET_BODY_CHUNK:
{
unsigned len = (unsigned)jk_b_get_int(msg);
jk_log(l, JK_LOG_DEBUG,
after many months of being away, i've recently gotten back into the fray of
jakarta-tomcat-connectors. my goal is as it was many months ago - an ajp
(v1.3) connector for tomcat 4.
after discovering that things are not working entirely correctly on the HEAD
of cvs, i started digging into the
I think we agreed ( Henri had some doubts ) that ajp14 will
consist only
on additional messages, but all the low-level messaging stuff will be
ajp13.
For that we only need a mechanism to register new message
handlers, and to
have a dispatcher that calls the right handler when a
i just happened to notice that the behaviour of tomcat 4 response buffers
might not be as expected with respect to buffer size. below is some code
from org/apache/catalina/connector/ResponseBase.java:
--- snip ---
public void write(byte b[], int off, int len) throws IOException {
it seems like a bunch of the stuff in the org.apache.tomcat.util.net package
in tomcat 3.x would be useful outside the scope of tomcat 3. most notably,
things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint.
what would people think about moving (or at least copying for now) this
One more change I want to do in jk2 is better error handling.
Most of us
spent enough time with java that using an 'int' is very
uncomfortable :-)
error handling good :) whether this is done by return codes, exceptions,
etc., personally, i don't care. what i do care about is
+1 ( part of it has already been moved ).
by part, you mean o.a.t.util.buf|collections|http|res, right?
But if we do that, I would propose to _move_ it, not copy.
ideally, you'd move the rcs archives to maintain history. however, doing
that would presumably break all tomcat 3.x
this patch fixes a problem when posting with more than about 8K of data. it
seems that when the java side of the ajp connection has to ask the webserver
(jk) side for more data, it goes into an infinite loop because the next
chunk of data isn't actually sent.
i'm 97% sure about this patch, but
i'm 97% sure about this patch, but since i don't know this
code as well as
some, i'd like someone else to review it.
This seems to be the main problem we had so far with jk -
buffers beeing
reused before they're ready. For jk2 we must make sure we have more
control over that or
this patch fixes a problem when posting with more than about
8K of data. it
seems that when the java side of the ajp connection has to
ask the webserver
(jk) side for more data, it goes into an infinite loop
because the next
chunk of data isn't actually sent.
i'm 97% sure about
If we move more and more logic and code in j-t-c, we may need
to have soon a specific jakarta-tomcat-connectors dev-list ?
There is today low java in jtc, mainly native code.
If all the 'ORB' java code is moved to j-t-c, for jk,
next maybe warp, and coyote also, we'll need to split
the
Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
code, right? I make this statement without having actually looked at
the code for the connectors. I'm going by recent discussions about
how an API change in Catalina broke the build for a connector.
some very small
The patch seems valid and the pmsg was passed for this
purpose in previous release of J-T-C but some folks
(didn't remember who) make modifications in mod_jk
part of code and the update was lost.
Seems ok, you could commit :)
done.
This patch fix a real problem and should be also
there hasn't been done anything on that topic yet ? What's
the status of
loadbalacing, either mod_jk or mod_webapp ?
Is that political due to if loadbalacing is working properly
there won't be
any reason to take (buy) anything else than TC ?
State of the art is that today only
I'm trying to figure out what I should do with the AJP
binaries, as the CVS
is a bit messy at the moment (and it includes two versions of
the sources).
I can:
- keep the current binary for b1
- try to upgrade, but I'd like to know which one I should use
(and the build
script
Hi,
After a lot of efforts, it turns out the connectors (in
j-t-c) still can't
be compiled against both the 4.0 branch and the HEAD branch
of the Tomcat
CVS.
There are a few solutions to this:
1) Force the connectors to be built against the HEAD branch.
They should run
fine
I'm trying to figure out what I should do with the AJP
binaries, as the CVS
is a bit messy at the moment (and it includes two versions of
the sources).
I can:
- keep the current binary for b1
- try to upgrade, but I'd like to know which one I should use
(and the build
the problem is the first file doesn't match the dtd for web.xml. i
believe tomcat 3 silently ignored this, whereas tomcat 4 doesn't.
Marjou Xavier wrote:
Hello
For information :
I got a problem with web.xml (attached File1 file) and Tomcat Milestone 4.0 b5:
PARSE error at line 18
One question who how to access md5 functions under
IIS/NETSCAPE ? (APR is not yet a solution :)
it looks you added md5 support (copied out of apache) directly into jk -
is this correct? i think this is probably the best solution for md5
functions in iis/netscape. i'm pretty sure there's
i've actually never had ajp13 working with iis. it's something i keep
meaning to get to, but haven't had time yet :(
i think somebody on the tomcat-dev list said they had it working once
...
i will look into this when i have a chance.
-kevin.
Ignacio J. Ortega wrote:
Hola Kevin:
+1
Craig R. McClanahan wrote:
I'd like to propose a modification to the way that the build scripts for
Tomcat 4 work, based on experience gained in the Jakarta Commons project,
Struts, and a couple of non-Jakarta projects that use the same approach.
Basically, the changes go like this:
i would guess the problems you are running into are related to .pl file
types not being associated with the perl executable. what distribution
of perl are you using? it's been a while... but the last time i
installed perl on windows, i used the active state dist
(http://www.activestate.com/)
which connector are you talking about? the new warp/webapp stuff, or
the ajp connector(s)? i don't know much about warp/webapp, but i do
know the ajp13 connector for tomcat 4 is a work in progress. it's kind
of in a holding pattern right now, waiting for some other things to
happen.
Regarding the connector - sorry I didn't had more time to spend on it, but
I'll be able to help more after I'll be back. I plan to do a
re-implementation of the java side of Ajp13/14, and also to do some
optimizations on the JNI side, and I'll try to help with the config stuff
( if Henri
The buffers do belong to jakarta-tomcat-connectors/util, and in a perfect
world we wouldn't have them duplicated - 3.3 should only use what's in
connectors.
I wouldn't mind making tomcat-connectors/util the master source for the
buffer stuff, but it needs some changes in the build
GOMEZ Henri wrote:
My question is what the status is on the apache connector in
tomcat 4. I've
been testing Jakarta 4 in standalone mode and is very pleased
with it, but
we can't run it like that once we release the system for all
our students..
;)
There is actually 2 connectors for
another
choice. you'll be free to make the decision yourself as to what
connector you want to use.
// Erik
-Original Message-
From: kevin seguin [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 28, 2001 3:05 PM
To: [EMAIL PROTECTED]
Subject: Re: connector status in tomcat 4
/webapp currently does not (no
iis/netscape support yet). hence, i would pick ajp.
now, i'm not saying one is better than the other. i'm just saying that
one might be better than the other in certain circumstances, and now you
have a choice.
Dave
[EMAIL PROTECTED]
From: kevin seguin [EMAIL
, too.
// Erik
-Original Message-
From: kevin seguin [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 28, 2001 5:47 PM
To: [EMAIL PROTECTED]
Subject: Re: connector status in tomcat 4
for example, in my case, currently all i care about is being able to
forward requests based
, short version
of instructions:
cvs co jakarta-tomcat-connectors
cd jakarta-tomcat-connectors/util
ant
cd ../jk
ant
i will be updating instructions, build.xml, etc. in the near future.
-kevin.
- Original Message -
From: kevin seguin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent
with the latest code from tomcat 3.3.
you didn't see the commit mail message, 'cause it was too big :)
it looks like the problem is you're using apache 1.3 (not multi-thread
on non-win32 systems) with a multi-threaded build of apr
(pthread_sigmask is an export from libpthread.so). i'm just guessing,
but i imagine you can build apr in single-thread mode...
Dave Oxley wrote:
I'm running RH7.1
for what it's worth, from the mentioned post, i believe this:
An other solution would be to use an APR without threads. To do so use
./configure --enable-threads=no when configuring APR.
rather than this:
I have no found exactly what happends but just add -lpthread in the
, if it was me, i'd use a singlethreaded version of
apr/mod_webapp with apache 1.3.
-kevin.
Martin van den Bemt wrote:
Do you believe in or is you choice better... I'm having some trouble now and
then with the mod_webapp...
Mvgr,
Martin
-Original Message-
From: kevin seguin [mailto
We could add it to jakarta-tomcat-connector ?
+1 -- so long as andy will help fix bugs in it when/if they come :)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A
+1
GOMEZ Henri wrote:
I would like to propose Mike Anderson as a new committer.
He found many subtils bugs in mod_jk and since he's
working on Netware platforms, it will a great help
to improve connectors on this OS.
Vote please
-
Henri Gomez ___[_]
EMAIL :
i think pier said he didn't care one way or the other, and that if
someone wanted to move mod_webapp/warp to jtc, they could go ahead and
do it -- but i shouldn't speak for pier :)
GOMEZ Henri wrote:
Did you, Pier, agree to move the mod_webapp/warp stuff
in jakarta-tomcat-connector and use
i feel like i could follow that readme file and get things building.
but, of course, i have not yet tried to build mod_jk in jtc :)
jean-frederic clere wrote:
Hi,
This README.configure is what I have prepared for the configure of mod_jk in
jakarta-tomcat-connectors.
Could you have a
tomcat 4 is not the right place to look for ajp13 examples. ajp14 is
still in the early stages, so you're probably better off starting with
ajp13. jakarta-tomcat-connectors/jk is probably the best place to look
for examples. there are ajp13 connectors for apache, iis and netscape.
you're
i was looking at the diffs here because i was going to propagate this
change to jakarta-tomcat-connectors, but i'm no sure i understand this:
public int getOffset() {
- return getStart();
+ return getEnd();
}
perhaps i'm missing something, but it looks like the
Ignacio J. Ortega wrote:
perhaps i'm missing something, but it looks like the offset
returned by
getOffset() should be the offset into the byte array contained in
ByteChunk, which would be the start position in this case, rather than
the end position.
From the point of view of
i'd like to propose Andy Armstrong as a new committer.
he has provided a connector for the lotus domino webserver
(http://free.tagish.net/domino-tomcat/index.jsp) which has recently been
incorporated into jakarta-tomcat-connectors.
please vote :)
-kevin.
+1
kevin seguin wrote:
i'd like to propose Andy Armstrong as a new committer.
he has provided a connector for the lotus domino webserver
(http://free.tagish.net/domino-tomcat/index.jsp) which has recently been
incorporated into jakarta-tomcat-connectors.
please vote :)
-kevin.
a couple quick thoughts (i haven't fully processed all of this yet
:))...
feels like the right thing to do is freeze ajp13, and only add new stuff
to ajp14. perhaps code can be refactored so that common stuff in
ajp13/14 can be pulled out of the ajp13 code and put into a common place
in
is not change ajp13. only
do new stuff in ajp14.
:!
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: kevin seguin [mailto:[EMAIL
GOMEZ Henri wrote:
A quick note to say that the secret key used in login phase
which was defined in mod_jk.conf (JkSecretKey/JkDefaultSecretKey)
is now set in workers.properties :
worker.ajp14.port=8011
worker.ajp14.host=localhost
worker.ajp14.type=ajp14
i'd be tempted to go with 1), but i like to live on the edge ;-) the
cvs repository is just a filesytem, after all... i suppose 2) would be
cleaner though. i guess i could go either way.
-kevin.
jean-frederic clere wrote:
Hi all,
I would like to move jakarta-tomcat-4.0/connectors to
jean-frederic clere wrote:
GOMEZ Henri wrote:
Could we change the naming of webapp to
make it matching jk...
ie :
webapp/src/native/apache-1.3
webapp/src/doc
webapp/src/native/include
webapp/src/java
webapp/src/native/lib
webapp/src/native/scandoc
i was just about to send a mail about that... i will do it :)
i planning on doing this directly in cvs (rather than doing cvs add or
cvs import). speak now if you have objections :)
-kevin.
GOMEZ Henri wrote:
Who could do that ?
Kevin/JF ?
-
Henri Gomez ___[_]
Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: kevin seguin [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 08, 2001 2:53 PM
To: [EMAIL PROTECTED]
Subject: Re: removing src level in jk for jtc
i was just about to send a mail about that... i will do
... in jtc/util and jtc/jk.
GOMEZ Henri wrote:
Could you also remove the unused apache1.3 and apache2.0.
We're using apache-1.3 and apache-2.0 now :)
they appear to have cvs rm'd, do you want them to be physically removed
too?
i'm not exactly sure what the intention was with having different
headers for webserver-container and container-webserver. i can only
assume it was to distinguish between the two directions. i'm not
exactly sure what the different header values buy you either... so,
unless someone has a good
1 - 100 of 199 matches
Mail list logo
