Slashdot Mirror

Keep in mind that Access XP includes a desktop version of SQL server

This is true, but you need to go back a couple years to get to the root of this (fscking stupid) idea.

Visio 2000 installs it by default as well. I can't remember if anything previous did, but that was my first encounter with this. I would love to buy a bag of whatever those in charge of making this idea a reality, but this is not a small thing. You need to consider the hundreds of thousadns (if not into the millions) that are running software that was created 2 or 3 years ago up to now (and the future holds suit as well).

Can someone please remind me why I have to keep using M$ garbage? OOo is a great package. There are MUCH better webservers out there, and there are MUCH BETTER SQL Servers out there.

I just don't get it...

Christ, they're right here dammit. The docs are great, watchoo talkin' 'bout Willis...

If that's not enough, go grab the servlet spec from Sun. It's really not that hard.

Yunno, I'm really getting sick of Fowler's "worse is better" nonsense trying to win back the day for "cowboy coders" who can't handle any discpline at all and want to treat critical production code as a playground.

Fowler's stuff isnt cowboy at all. It actually takes a lot of discipline to follow what he actually says in his book (writing tests to ensure that each refactoring is safe). His book is a series of recipes for how to introduce changes safely, not a rally call for changing code because you feel like it today. The Refactoring book can help people working in any methodology (except perhaps the 'Personal Software Process' and its variants, which want you to learn to write code right first time, and are less realistic for code maintenance). XP gets a mention but its not an XP book.

Meaninglessly vague. Is javadoc boilerplate?

Meaning 1 on wordnet is "a standard formulation of legal documents or news stories". Now look at this (code from Tomcat). See the boilerplate comment at the top? Its NOT THE JAVADOC - its the license. There are tools like jalopy which help you maintain this cruft but like I say it helps noone but lawyers.

This guy must have a massively cool source control tool that actually shows him the changelog on a per-function basis, and automatically senses and shows only the changes that are significant, like an interface change.

The 'change history comment' is the old practice of writing in a history of changes at the top of the file (not on a function by function basis as you suggest) duplicating the comment recording in the source code control system, while not necessarily recording all changes because it isnt /driven/ by that system. VSS, CVS, etc can show you the changelog externally, or you can include a $Keyword$ to get the changelog included in the comment and maintained for you. As for knowing which change is significant - developers don't know this either. The change which breaks things is the significant one and they usually don't realise they've done it at the time. Interfaces changes, while high cost, are actually less significant causes of error since they are easily caught by static checks. It is the changes in behaviour that will get you.

We don't always get to write everything from scratch...

This is true. often you'll not get to rename the methods of some dumbly named third party interface. And in this case the comment is inevitable. Note I did say not all comments are bad. I'm asking you to question them.

Another smaller, uncommented method no doubt.

Yes, exactly. If the smaller method is 4 lines long, has a blindingly obvious name, and is in the private interface of the class (often the case for extracted methods like this), the comment is superfluous.

Previously I've attempted a description of the success of an Open Source product, Ant, in terms of the Innovator's Dilemma. I think the fit is very good, provided you recognize how the rewards and costs should be measured in the OSS environment. If you are interested it can be found at Ant as an Example of the Innovator's Dilemma. Now I'll have to go back and see how Ant matches against the guidelines in the article, so far it's looking pretty good.

I myself do custom work for small businesses for a living. I'm a Java guy who's into open source, here's how I typically work:

• Gather requirements duh. You gotta find out what they really need, obviously. Not always clear, but that's part of the job - translating their requirements on a business level into concrete development action.
• Sell the Client on pre-existing OSS frameworks In my case, server-side web development w/ Java, this almost always includes Tomcat. Not GPL'd, but hey, certainly better than the other, proprietary crap. Lately I've been doing more involved projects, so I've been pushing JBoss as well, which _is_ GPL'd and frankly fantastic as well. I try and run these on Linux w/ Apache if possible. I find this is not a hard sell - the main points being no licensing costs for them, more stable tools than the proprietary solutions, etc. These are also popular well-known systems which always makes business types feel better than unknown sketchy things.
• Use pre-existing OSS libraries for the general parts For me this means class libraries - if I need logging I use log4J, if I need XML processing I use Xerces, etc. (well bad examples since they're APL, not GPL, but you get the point). I also make this clear to the client, they usually like the idea as it saves development time and thus their money. I also let them know that any code I write to improve these libraries goes back to the project and is not the ownership of the client. This is also not a hard sell - my client doesn't care about owning parts of a logging system, it's not his business. This is how I get to contribute to OSS on the client's dime.
• Write the custom bits Given the above, all that's left is business logic and design. For me this means incorporating the client's business logic in a bunch of servlets of EJBs, and their front end design into a JSP page or an XSLT template. I typically give them full IP ownership of this - yes, I charge a higher rate b/c of this, and frankly this shit is useless to me outside of the current project anyway.

There are two UNIX/Linux solutions to that startup overhead problem. One is to build the transaction program into the network application (as in Apache/mod_perl/php). Note that this uses an interpreter to protect the network application from bugs in transaction programs, which is a major performance hit.

Websphere Portal Server (a Websphere add-in) is built on top of Jetspeed, an Apache/Jakarta project.

There has been a fair number of posts about whether or not Java is really an "Open-Standard". The first thing to remember is where this article originates, Business 2.0.

Taking that into account, Java is an open standard. Are there other compilers for Java? Yes. Are there multiple interpreters for Java? Yes. Is the standard published on how it works? Yes (Addison-Wesely publishes several books on it). So, for the average intended reader of business 2.0, Java is an open standard.

I'm probably going to get flamed for this, but something doesn't have to be controlled by an international standards organization to be open.

Now, if you'll excuse me, I'm going to go prepare for flames as I've posted something that people are going to have problems with.

No, mod_perl 2.0 isn't done yet. It's still under development, and there have been users who's been able to compile it under Win32 and UNIX platforms.

More information can be found at http://perl.apache.org/, which includes links to mailinglist archives with some interesting info.

As for ./, they seem to be running Apache 2.0 on some of the support servers (ie. servers that don't server dynamic content). Me, on the other hand, still prefer TUX to do this static content job.

--
We're dealing with a real maniac here. Let's go buy some donuts.

No, mod_perl 2.0 isn't done yet. It's still under development, and there have been users who's been able to compile it under Win32 and UNIX platforms.

More information can be found at http://perl.apache.org/, which includes links to mailinglist archives with some interesting info.

As for ./, they seem to be running Apache 2.0 on some of the support servers (ie. servers that don't server dynamic content). Me, on the other hand, still prefer TUX to do this static content job.

--
We're dealing with a real maniac here. Let's go buy some donuts.

On a related note, going through customs recently got me wondering about import duties on electronic file downloads across borders. Since the import duty is supposed to be on the value of the item (not what you claim you paid for it -- "I got this Rolex for $5"), then what is the "value" of Apache? Should I claim warze even though I pay nothing for them? Should I shut up, lest I give them ideas?

Cast as inputHandler,
Arguments enter as streams
Call getParser next.

Their Spacial Database Engine (SDE) runs on many databases including Unix, but those who have had to work with it in my agency havn't had much good to say about it. It does work, but backwards compatibility doesn't seem to be a priority with ESRI and our developers have to check everything. Whenever I bring it up, even in the GIS department, there is always a groan of discontent.

ArcInfo is a windows only based product as of version 8. You can still get ArcInfo version 7.something for Solaris but last I heard they don't plan on making another Unix version. They do alot with "map objects" which is as I understand it very useful in Visual Basic and other COM based RADs but useless outside of windows.

They do have a new version of ArcIMS (Internet Mapping Server) which runs on the Struts framework from the Jakarta project. We just got version 4.0 a couple days ago but havn't opened the box yet. Hopefully it will be better than previous versions. I can say that ArcIMS 3.1 was MUCH better than ArcIMS version 3.0.

As a web developer I have been lusting over MapInfo's products but alas we already have ERSI in house and MapInfo and ESRI have never played well together.

If I wanted to deploy on a unix platform, just from what I have heard and seen thus far, I would look at MapInfo's product unless there is something you need that they can't do and ESRI can.

JUnit is amazing. It's incredibly easy after you've written your first unit test. Here is a prime example of its use: I had about 50 classes spread out over a couple packages one of which is "core" to all the others. I had unit tests for all the code. I wanted to totally redesign how I implemented one of the core classes which is inherited by a number of other classes. I think people that don't have unit tests would shy away from such a large change. I simply backed up the old source file, put in the new file, and ran my ant script which builds, deploys (on appserver) and runs junit. After about 20 minutes of cranking through the unit tests, it finished with no failures. At that point I was 100% confident that my change worked and I wouldn't be surprised by a suble bug later. That is what junit is good for - peace of mind and confidence. You'll allow yourself to make changes to code (for the better) that you may otherwise have though too complex to attempt.

As for your first unit test, it isn't that hard. Use a standard naming schema like "FooTest.java" or "FooJUnit.java" for your test cases - this way ant can filter on those name and run junit against them while keeping your unit tests out of your distribution jars. Extend TestCase and overload setUp() and tearDown() - often you won't need those. Name your methods testXYZ() and junit will run them. Inside your test methods call Assert.xxx() on the things you want to test. You can test for null, compare to known values, etc. You can test to make sure exceptions should be thrown or not. Sprinkle in a little log4j and you can get more detailed progress of the tests.

-tim

What does Ant (an extremely useful buildtool for Java) have to do with Extreme programming? Nothing! I can't really imagine why anyone would need a book on Ant (can't say much for the others) -- there's pretty self explanatory documentation here. Since extreme programming strikes me as a load of crap to begin with, this is all probably a good thing.

YOur right about the amazon reviews. What is it with these "reviews" that get posted here -- the table of contents for christ sakes? It seems like book reviews are just an excuse to post a affiliate link to a book store. For shame slashdot. For shame...

I've used extensions for some of the things that I couldn't easily do in XSL.
Takle a look at the Xalan extensions, or find something for your implementation.

There's a common assumption that SOAP is only transported via HTTP.

From the Apache SOAP faq

The writers of the SOAP 1.1 protocol [http://www.w3.org/TR/SOAP/] note that: 'SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework'.

eg. you can transport SOAP via SMTP.

This is slightly off topic but almost anyone can compress text, too. Of course, JPG compression is better than text compression but every little bit counts.

You can download a copy of mod_gzip here for Apache.

Your conditions are not complete: you must also allow for browsers that do not provide a REFERER. The browser 'links' for instance (which DOES provide image downloading by simply pressing 'ENTER' on an image link) does not provide REFERER for privacy reasons. Junkbuster can also be set up in a similar manner.

Preventing linking from REFERERs that are not yours, and not empty, will have the same discouraging effect on the linkers, without blocking valid users of your site.

You can do this without mod_rewrite, as shown on the apache web site: Environment Variables (at the bottom).

I would not be happy if some other site linked right to the old material, because they might not put it in context, and lead people into thinking it is current.

Then maybe you should use mod_rewrite with a simple rule:

RewriteCond %{HTTP_REFERER} !^http://your.host/ [NC]
RewriteRule ^/old-stuff/(.*)$ /cgi-bin/old-warn?page=$1 [R]

and put there a simple old-warn script displaying "This stuff is old. What do you want? [New] [Old] [Index] [Home] [Whatever]". Or why not include this warning on the old pages in the first place? Or why not to just put "Last modified XXXX-XX-XX, if there's a newer version, it's here." on every page which can be outdated in the future?

Linking is just telling people about your URI. If you don't want them to know about it, don't make it public, you don't have to serve anything if you don't want to. If you want those people to see something before they get what they are looking for, I don't know what's stopping you. The beauty of computers, including web servers, is that they do what you tell them to do.

Web-Surfing Indian Slum Kids Ask: "What's a Computer"

I heard that they are great in ASF HTTP Server administration. I wonder why.

(Or are they Indians from Indies? Damn you Cristoforo Colombo!)

Anyway, I would choose SVG over flash any day.

i knew it was getting popular. but a coastline? bravo.

ColdFusion is certainly functional, but not very robust. Can it do most of the basic things that other server-side languages do? Sure. But with the advent of MVC models such as Struts this need is diminished. Or if Struts is too much, then you can build your own custom tags, or use existing JSP custom tag libraries. This allows for your non-CS HTML people to do things such as:

<table>
<sql:statement id="stmt1" conn="conn1">
<sql:query>
select id, name, description from test_books
order by 1
</sql:query>
<%-- loop through the rows of your query --%>
<sql:resultSet id="rset2">
<tr>
<td><sql:getColumn position="1"/></td>
<td><sql:getColumn position="2"/></td>
<td><sql:getColumn position="3"/>
<sql:wasNull>[no description]</sql:wasNull></td>
</tr>
</sql:resultSet>
</sql:statement>
</table>

The last project I worked on used this, and the designers (HTML people, with some basic JavaScript experience) were able to pick up on it after a single half-day meeting. Very simple, very straightforward, very robust, and you don't have to drop several thousand bucks into a technology that even Macromedia is showing signs of moving away from.

ColdFusion is certainly functional, but not very robust. Can it do most of the basic things that other server-side languages do? Sure. But with the advent of MVC models such as Struts this need is diminished. Or if Struts is too much, then you can build your own custom tags, or use existing JSP custom tag libraries. This allows for your non-CS HTML people to do things such as:

<table>
<sql:statement id="stmt1" conn="conn1">
<sql:query>
select id, name, description from test_books
order by 1
</sql:query>
<%-- loop through the rows of your query --%>
<sql:resultSet id="rset2">
<tr>
<td><sql:getColumn position="1"/></td>
<td><sql:getColumn position="2"/></td>
<td><sql:getColumn position="3"/>
<sql:wasNull>[no description]</sql:wasNull></td>
</tr>
</sql:resultSet>
</sql:statement>
</table>

The last project I worked on used this, and the designers (HTML people, with some basic JavaScript experience) were able to pick up on it after a single half-day meeting. Very simple, very straightforward, very robust, and you don't have to drop several thousand bucks into a technology that even Macromedia is showing signs of moving away from.

http://www.apache.org/server-status

And is it easy to set up to be able to run ISAPI applications?
It's very easy to run the java equivalent to a ISAPI, install Tomcat, plock .war in the correct folder. (alas this has a slight overhead with the VM (as with .NET))

And for ISAPI add the line
ISAPICacheFile d:/rive/and/path/to/the.dll

Not quite as easy as IIS, but (alas) very few OS apps are.

mlk

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

I've always found it frustrating that the superior products produced by the Apache foundation are so sorely underrated by the mainstream media. Buzzwords like "BroadVision" and "WebSphere" are pounded into the heads of middle management by way of large advertising budgets. The truth is, however, that I can do anything a BroadVision developer can do *with no software cost whatsoever*

Cocoon is a brilliant publishing system which combines many of the Apache projects: Xalan for XSLT transformations of all kinds, FOP for building dynamic PDFs (don't pay Adobe but use their format anyway :-) from XSL:FO, Batik for building dynamic SVGs, and a ton of library code that makes building dynamic websites very easy.

Not to mention, Apache has provided us with solid implementations of *many* w3c and Java specifications, including SOAP for XML based RPC, and JServ and Tomcat Java servlet engines.

My point is only this: appreciate The Apache Foundation because they totally rock!

Set up tomcat /w SOAP, and show a simple VB app or ASP page interacting with a "hello world" SOAP call. Real world, simple setup, shows the potential to mix environments...

And herbalifesigns.com is running Apache 1.3.20, the newest version being 1.3.24. ChangeLog here. Hmm... SecurityFocus discusses a misconfiguration of Apache that allows remote users to determine if a given username exists on a system. Although the advisory mentions Red Hat Linux, the default configuration of Apache 1.3.20 is also affected

With one notable exception, he might be correct.

When was the last time someone did a code review on the linux kernel? What's that? It's never happened?

Face it, with a few exceptions, the Open Source community is focused on creating a product, not on creating a secure product. It is this mentality that produces a lot of the products you use today, unfortunately, its the same mentality that causes a few dozen security holes to be discovered weekly.

Its not necessarily a bad thing, but the open source community, as a whole, doesnt do much in the way of code audits.

Check out Jakarta ORO, a Perl 5 Compliant Regular Expression Library for Java at http://jakarta.apache.org/oro/

I've been using this on my Java projects for years, works great! (Of course you have to know how to write Perl 5 regexes, an art in itself!)

Also Java 1.4 is FINALLY bundling some sort of regex library in it's core API, but I haven't messed with it yet.

[You'd be amazed at how many copies of things there are to update on the apache.org websites when putting out a release. :]

The document he built describing what was coming with mod_perl 2.0 hasn't even been updated since Aug 2001! Many people would like to see some sort of status message. Does anyone know how well the cvs version works? Are there any major bugs?

-1 offtopic +1 interesting
this may seem offtopic, but did anyone notice from the link provided by this parent comment that apache gained 2.59% in one month? microsoft lost .98%
do you think this is because of the recent recession, the new version of apache being expected, or the recent security problems in the last year with IIS?

just food for thought.

They say it here for the win32 binaries at least.

Apache 1.3.24 is the best version of Apache currently available; everyone running 1.2.X servers or earlier are strongly urged to upgrade to 1.3, as there will not be any further 1.2.X releases. At present, the Win32 port of Apache is not as stable as the UNIX version.

Apache 2.0 offers numerous enhancements, improvements and performance boosts over the 1.3 codebase

Slashdot is running Apache 1.3.20. They will probably run 1.3.24 (currently the latest 1.3.x) before moving to 2.0.

Does anyone know when a new mod_perl will be available? The current mod_perl (1.26) was released in July 2001.

If you are planning on using mod_proxy, I would recommend sticking with 1.3.20, or wait until 1.3.25 is released. Why? The new mod_proxy code has a bug which won't "downgrade" HTTP 1.1 responses sent from the proxy to upstream HTTP servers. Which means if you have a HTTP 1.0 browser (Netscape 4.*) and you access a site proxied with Apache 1.3.24 (or anything past 1.3.21 methinks) you will get a bunch of garbage displayed on the page (the HTTP 1.1 "de-chunking" byte markers)

Here's the bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7513


Also, the 1.3.24 mod_proxy code so far still has the following bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7195
(mod_proxy munches cookies if number of cookies > 1)

http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7572
(mod_proxy ignores "Timeout" directive and cuts off long up/downloads)

Even the best of software have its share of bugs.

If you are planning on using mod_proxy, I would recommend sticking with 1.3.20, or wait until 1.3.25 is released. Why? The new mod_proxy code has a bug which won't "downgrade" HTTP 1.1 responses sent from the proxy to upstream HTTP servers. Which means if you have a HTTP 1.0 browser (Netscape 4.*) and you access a site proxied with Apache 1.3.24 (or anything past 1.3.21 methinks) you will get a bunch of garbage displayed on the page (the HTTP 1.1 "de-chunking" byte markers)

Here's the bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7513


Also, the 1.3.24 mod_proxy code so far still has the following bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7195
(mod_proxy munches cookies if number of cookies > 1)

http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7572
(mod_proxy ignores "Timeout" directive and cuts off long up/downloads)

Even the best of software have its share of bugs.

If you are planning on using mod_proxy, I would recommend sticking with 1.3.20, or wait until 1.3.25 is released. Why? The new mod_proxy code has a bug which won't "downgrade" HTTP 1.1 responses sent from the proxy to upstream HTTP servers. Which means if you have a HTTP 1.0 browser (Netscape 4.*) and you access a site proxied with Apache 1.3.24 (or anything past 1.3.21 methinks) you will get a bunch of garbage displayed on the page (the HTTP 1.1 "de-chunking" byte markers)

Here's the bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7513


Also, the 1.3.24 mod_proxy code so far still has the following bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7195
(mod_proxy munches cookies if number of cookies > 1)

http://nagoya.apache.org/bugzilla/show_bug.cgi?id= 7572
(mod_proxy ignores "Timeout" directive and cuts off long up/downloads)

Even the best of software have its share of bugs.

From the acticle... Software developers who want to dispense with Section 5's limitations can turn to schema-based serialization. This method works by publishing the interfaces of the SOAP service along with the schema(s) for the request/response messages. Web Services Definition Language (WSDL) is the current de facto standard for this purpose. Apache SOAP is not WSDL aware, but Axis (see Resources), Apache SOAP's successor toolkit, is.

The lack of WSDL support in the apahce toolkit is a huge limitation of this toolkit if you wish to utilize remote web services. However the axis project at apache does look like it will provide a solution to this problem. Although the axis project is still in beta stages, it looks like it will be a killer implemetation once it matures. If you are planning on working with Java and SOAP in the future, then you really should take a look at axis. Beta, but worth it ;)

From the acticle... Software developers who want to dispense with Section 5's limitations can turn to schema-based serialization. This method works by publishing the interfaces of the SOAP service along with the schema(s) for the request/response messages. Web Services Definition Language (WSDL) is the current de facto standard for this purpose. Apache SOAP is not WSDL aware, but Axis (see Resources), Apache SOAP's successor toolkit, is.

The lack of WSDL support in the apahce toolkit is a huge limitation of this toolkit if you wish to utilize remote web services. However the axis project at apache does look like it will provide a solution to this problem. Although the axis project is still in beta stages, it looks like it will be a killer implemetation once it matures. If you are planning on working with Java and SOAP in the future, then you really should take a look at axis. Beta, but worth it ;)

The 404 message coming back is the standard IIS one, and it is even labelled as IIS.

It's easy to get Apache HTTP Server to lie about its identity. Just capture the II$ error page, save it as 404.html, and use the Apache ErrorDocument directive to serve that page as the HTTP error result. Repeat this for II$'s other error pages, and you perpetuate the lie.