Re: HTTPD upgraded on eos -> 2.3.8
On Tue, Aug 24, 2010 at 10:59 PM, Ruediger Pluem wrote: > > > On 08/25/2010 02:10 AM, Tony Stevenson wrote: >> On Wed, Aug 25, 2010 at 01:04:01AM +0100, Tony Stevenson wrote: >> >>> Had to comment out an output filter line in the main httpd.conf (line 117) >> >> More specifically had to disable deflate - "AddOutputFilterByType DEFLATE >> text/html text/plain text/xml application/xml application/xml+rss text/css >> application/x-javascript" >> The deflate module is loaded, and seemingly not causing any outwardly >> obvious issues >> >> Thoughts? > > AddOutputFilterByType moved from core to mod_filter (see > http://svn.apache.org/viewvc?rev=966869&view=rev) > > So I guess mod_filter is not loaded. If it is the line should work again. > Grump old man mode, this seems moderately disturbing. Previously it was single hash table look up on the content-type, which contained a list of all filters to apply. It has been replaced with iterating all possible filters and executing an the expression parser for each possible filter. Is anyone else surprised at this change? I did a quick search on dev@, and I couldn't find any previous discussion of this change
httpd trunk broken with Subversion: ap_log_rerror busted
In r951893, httpd modified a #define for APLOG_MARK to add in a new parameter called APLOG_MODULE_INDEX (in addition to file and line info). This busts Subversion - specifically, mod_authz_svn which has a function called: static void log_access_verdict(const char *file, int line, const request_rec *r, int allowed, const char *repos_path, const char *dest_repos_path) it is called with: log_access_verdict(APLOG_MARK, r, 1, repos_path, dest_repos_path); Reading the very obtuse (unhelpful) commit log for r951893 as well as any comments in that general area of http_log.h (which are lacking & unhelpful), I have no idea what this APLOG_MODULE_INDEX is or why it's even there. Furthermore, this error case is very very hard to track down because we're relying upon multiple levels of #define's and indirections (hidden static variables??, weird STDC wrappers, redefinitions of function names, etc, etc.). So, it's not going to be obvious to downstream developers what is going on and why it is broken. In general, I'm not quite sure it's a good idea to bust a #define that has been the same since the 1.3 days (if not earlier actually). If we want modules to use a new optimized log API, then we should introduce a new optimized log API and not bust the old one in a way that the failure case isn't obvious to track down. Yes, we could fix this by making mod_authz_svn conditional on the new MMN, but - again, it's about even figuring out that the API is changed and what to do about it. The root cause is just way too obscured, IMO. (I wish I could veto this whole commit just on over-complication alone - it's not an elegant solution at all.) My $.02. -- justin
Re: HTTPD upgraded on eos -> 2.3.8
On 08/25/2010 02:10 AM, Tony Stevenson wrote: > On Wed, Aug 25, 2010 at 01:04:01AM +0100, Tony Stevenson wrote: > >> Had to comment out an output filter line in the main httpd.conf (line 117) > > More specifically had to disable deflate - "AddOutputFilterByType DEFLATE > text/html text/plain text/xml application/xml application/xml+rss text/css > application/x-javascript" > The deflate module is loaded, and seemingly not causing any outwardly obvious > issues > > Thoughts? AddOutputFilterByType moved from core to mod_filter (see http://svn.apache.org/viewvc?rev=966869&view=rev) So I guess mod_filter is not loaded. If it is the line should work again. Regards Rüdiger
Re: [PRERELEASE TARBALLS] httpd-2.3.8
On 08/25/2010 12:29 AM, Paul Querna wrote: > On Tue, Aug 24, 2010 at 3:04 PM, Guenter Knauf wrote: >> Hi all, >> Am 24.08.2010 18:42, schrieb Jim Jagielski: >>> The pre-release test tarballs for httpd-2.3.8 (alpha) are >>> available for download, test and fun: >>> >>>http://httpd.apache.org/dev/dist/ >>> >>> Will call for a release vote in a coupla days... >> I know that this topic was already up here, but nevertheless I think we >> should re-think about including PCRE again. >> Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and >> I see no benefit in dropping it from our dependencies deliveries other than >> making tarballs smaller, and that is nowadays certainly not an issue >> anymore. >> We want Apache to build form source on at many platforms as possible - sure >> the main target is Linux / Unix, but we have a couple of other platforms >> where PCRE is not installed by default, that are at least Win32, NetWare, >> most likely OS/2, and probably a couple of others too. >> I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went >> fine only because I have an (self) adapted makefile (from previous times >> when we shipped PCRE), the Win32 stuff is horrible: there comes some >> suggestion up that I should build PCRE with CMake with xxx option; 1st I >> have to download CMake and depend on another build tool (ok, not that big >> issue), but whats even more worse is that the CMake build failed for me, and >> thats really bad - you cant just go and build httpd as you do on Linux, no! >> Your build process is always interupted, and probably as in my case finally >> broken at all. >> Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our >> own makefile, and the build goes through in one go without need for other >> tools like CMake - just the compiler and probably a platform PDK are enough >> (and thats how it shoud be). >> Therefore I want to start a vote here again where we vote for including PCRE >> again with the dependencies - just as we (now) do with APR/APU; >> and everyone who votes against should give some good reasons what speaks >> against -- the fact that every Linux comes with PCRE is certainly no good >> reason - it only leads finally to the fact that we might end up with 50 >> builds of httpd 2.after-2.x with different PCE versions which makes then >> nice bug hunting, and we cant even tell someone who faces a prob to 'use our >> shipping PCRE which is known to be good'. >> >> Here we go: >> >> [ ] YES - include recent PCRE again with dependencies (means we >>create a PCRE repo in svn, check in a recent version, and add >>platform-dependent makefiles which are fully integrated into >>main build process). >> >> [ ] NO - dont include PCRE (as currently) because of reason: ... >> > [X] NO: > > There are 3-5 PCRE releases per year[1], and as a project our history > of staying up to date (including security and just bug fixes) was > generally pretty bad. Bundling our own PCRE is a security risk best > managed by operating system vendors who take care of backporting > patches to 4 year old versions, as an upstream I see very little value > in maintaining PCRE in tree, and plenty of risks. > > It seems to enable porting on other platforms, we could make a shell > script that downloaded PCRE and any other dependencies like it > (OpenSSL?), but I don't believe this has a place in the main > distribution tarball. Very valid reasons and I am as a 'Unix' guy not hurt that much by the stopped bundling of PCRE. OTOH there seems to be a real problem on Netware and Windows and we might should spend some time in providing better build instructions / scripts how to get PCRE build easily on Windows / Netware. Regards Rüdiger
Re: HTTPD upgraded on eos -> 2.3.8
On 25 August 2010 10:10, Tony Stevenson wrote: > On Wed, Aug 25, 2010 at 01:04:01AM +0100, Tony Stevenson wrote: > >> Had to comment out an output filter line in the main httpd.conf (line 117) > > More specifically had to disable deflate - "AddOutputFilterByType DEFLATE > text/html text/plain text/xml application/xml application/xml+rss text/css > application/x-javascript" > The deflate module is loaded, and seemingly not causing any outwardly obvious > issues > > Thoughts? What is the actual problem that caused you to remove it? If you are seeing problems when this output filter is being used, is it for URLs which are being handled by whatever Python web application you are hosting via mod_wsgi? I ask as I have had two reports of people having issues when using DEFLATE on mod_wsgi responses. Feedback suggests that responses are being delayed in being sent, giving appearance of slow response. The information I have is confusing however, as one person suggested it only happened for mod_wsgi daemon mode and the other thought it was only mod_wsgi embedded mode. I have not got enough information back from anyone to try and work out what issue may be and could not duplicate a problem myself in testing with standard Apache on Mac OS X. But then, I may well not have configured it in same way as people having problem. Graham > -- > Cheers, > Tony > > > Tony Stevenson > > t...@pc-tony.com - pct...@apache.org > pct...@freenode.net - t...@caret.cam.ac.uk > > http://blog.pc-tony.com > > 1024D/51047D66 > >
Re: HTTPD upgraded on eos -> 2.3.8
On Wed, Aug 25, 2010 at 01:04:01AM +0100, Tony Stevenson wrote: > Had to comment out an output filter line in the main httpd.conf (line 117) More specifically had to disable deflate - "AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xml+rss text/css application/x-javascript" The deflate module is loaded, and seemingly not causing any outwardly obvious issues Thoughts? -- Cheers, Tony Tony Stevenson t...@pc-tony.com - pct...@apache.org pct...@freenode.net - t...@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66
HTTPD upgraded on eos -> 2.3.8
As the subject says, httpd is now on 2.3.8 for www.apache.org apr is at trunk mod_wsgi was upgraded to 3.3 (http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz) Had to comment out an output filter line in the main httpd.conf (line 117) Other than that HTTPD started up just fine. http://www.apache.org/server-status -- Cheers, Tony Tony Stevenson t...@pc-tony.com - pct...@apache.org pct...@freenode.net - t...@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66
Re: [PRERELEASE TARBALLS] httpd-2.3.8
A loud resounding "Amen" to Guenter from the Windows balcony. I have reservations however. 1. I have a patch that let's me build trunk with the PCRE 5.0 from 2.2, but I do not want to stay at PCRE 5.0 cause you have to have something newer to link mod_security 2.5.12+ against, so I have to build something newer regardless (not that any 3rd party module even works in 2.3.x at the moment). 2. I have no problems building PCRE 8 on Windows w/ CMake and dropping the 4 files in srclib/pcre. The annoyance is makefile.win wanting to copy the non-existing pcre.pdb and barfing there. Another patch ;-) 3. I have not been able to get pcre 8 (current 8.10) to build in tree like pcre 5 on 2.3.x, in 2.2.x yes. The static lib seems to not export some needed symbols (pcre_free comes to mind as one). I have not tried building in tree as DLL however. While not ignoring Paul's comments included with his NO vote, as I see it, there are three different build systems included in the tarballs, Windows, Netware and one for most flavors of Unix. We get the code for mod_suexec which in not built on Windows and just sits there dormant, why could PCRE not be included (for Windows and Netware and OS/2 and ?) and just simply not be included in the makefiles and sit there dormant in the different flavors of Unix as mod_suexec does on Windows/Netware? So if I could vote, I'd vote +0.5 till I knew what version you were planning on including and it would only go to a full 1 if pcre was not built on Unixs' and was newer than 6.5 (the mod_security minimum IIRC). Regards, Gregg Guenter Knauf wrote: Hi all, Am 24.08.2010 18:42, schrieb Jim Jagielski: The pre-release test tarballs for httpd-2.3.8 (alpha) are available for download, test and fun: http://httpd.apache.org/dev/dist/ Will call for a release vote in a coupla days... I know that this topic was already up here, but nevertheless I think we should re-think about including PCRE again. Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and I see no benefit in dropping it from our dependencies deliveries other than making tarballs smaller, and that is nowadays certainly not an issue anymore. We want Apache to build form source on at many platforms as possible - sure the main target is Linux / Unix, but we have a couple of other platforms where PCRE is not installed by default, that are at least Win32, NetWare, most likely OS/2, and probably a couple of others too. I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went fine only because I have an (self) adapted makefile (from previous times when we shipped PCRE), the Win32 stuff is horrible: there comes some suggestion up that I should build PCRE with CMake with xxx option; 1st I have to download CMake and depend on another build tool (ok, not that big issue), but whats even more worse is that the CMake build failed for me, and thats really bad - you cant just go and build httpd as you do on Linux, no! Your build process is always interupted, and probably as in my case finally broken at all. Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our own makefile, and the build goes through in one go without need for other tools like CMake - just the compiler and probably a platform PDK are enough (and thats how it shoud be). Therefore I want to start a vote here again where we vote for including PCRE again with the dependencies - just as we (now) do with APR/APU; and everyone who votes against should give some good reasons what speaks against -- the fact that every Linux comes with PCRE is certainly no good reason - it only leads finally to the fact that we might end up with 50 builds of httpd 2.after-2.x with different PCE versions which makes then nice bug hunting, and we cant even tell someone who faces a prob to 'use our shipping PCRE which is known to be good'. Here we go: [ ] YES - include recent PCRE again with dependencies (means we create a PCRE repo in svn, check in a recent version, and add platform-dependent makefiles which are fully integrated into main build process). [ ] NO - dont include PCRE (as currently) because of reason: ... thanks, Gün.
Re: [PRERELEASE TARBALLS] httpd-2.3.8
On Tue, Aug 24, 2010 at 3:04 PM, Guenter Knauf wrote: > Hi all, > Am 24.08.2010 18:42, schrieb Jim Jagielski: >> >> The pre-release test tarballs for httpd-2.3.8 (alpha) are >> available for download, test and fun: >> >> http://httpd.apache.org/dev/dist/ >> >> Will call for a release vote in a coupla days... > > I know that this topic was already up here, but nevertheless I think we > should re-think about including PCRE again. > Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and > I see no benefit in dropping it from our dependencies deliveries other than > making tarballs smaller, and that is nowadays certainly not an issue > anymore. > We want Apache to build form source on at many platforms as possible - sure > the main target is Linux / Unix, but we have a couple of other platforms > where PCRE is not installed by default, that are at least Win32, NetWare, > most likely OS/2, and probably a couple of others too. > I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went > fine only because I have an (self) adapted makefile (from previous times > when we shipped PCRE), the Win32 stuff is horrible: there comes some > suggestion up that I should build PCRE with CMake with xxx option; 1st I > have to download CMake and depend on another build tool (ok, not that big > issue), but whats even more worse is that the CMake build failed for me, and > thats really bad - you cant just go and build httpd as you do on Linux, no! > Your build process is always interupted, and probably as in my case finally > broken at all. > Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our > own makefile, and the build goes through in one go without need for other > tools like CMake - just the compiler and probably a platform PDK are enough > (and thats how it shoud be). > Therefore I want to start a vote here again where we vote for including PCRE > again with the dependencies - just as we (now) do with APR/APU; > and everyone who votes against should give some good reasons what speaks > against -- the fact that every Linux comes with PCRE is certainly no good > reason - it only leads finally to the fact that we might end up with 50 > builds of httpd 2.after-2.x with different PCE versions which makes then > nice bug hunting, and we cant even tell someone who faces a prob to 'use our > shipping PCRE which is known to be good'. > > Here we go: > > [ ] YES - include recent PCRE again with dependencies (means we > create a PCRE repo in svn, check in a recent version, and add > platform-dependent makefiles which are fully integrated into > main build process). > > [ ] NO - dont include PCRE (as currently) because of reason: ... > [X] NO: There are 3-5 PCRE releases per year[1], and as a project our history of staying up to date (including security and just bug fixes) was generally pretty bad. Bundling our own PCRE is a security risk best managed by operating system vendors who take care of backporting patches to 4 year old versions, as an upstream I see very little value in maintaining PCRE in tree, and plenty of risks. It seems to enable porting on other platforms, we could make a shell script that downloaded PCRE and any other dependencies like it (OpenSSL?), but I don't believe this has a place in the main distribution tarball. Thanks, Paul [1] - http://www.pcre.org/news.txt
Re: [PRERELEASE TARBALLS] httpd-2.3.8
Hi all, Am 24.08.2010 18:42, schrieb Jim Jagielski: The pre-release test tarballs for httpd-2.3.8 (alpha) are available for download, test and fun: http://httpd.apache.org/dev/dist/ Will call for a release vote in a coupla days... I know that this topic was already up here, but nevertheless I think we should re-think about including PCRE again. Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and I see no benefit in dropping it from our dependencies deliveries other than making tarballs smaller, and that is nowadays certainly not an issue anymore. We want Apache to build form source on at many platforms as possible - sure the main target is Linux / Unix, but we have a couple of other platforms where PCRE is not installed by default, that are at least Win32, NetWare, most likely OS/2, and probably a couple of others too. I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went fine only because I have an (self) adapted makefile (from previous times when we shipped PCRE), the Win32 stuff is horrible: there comes some suggestion up that I should build PCRE with CMake with xxx option; 1st I have to download CMake and depend on another build tool (ok, not that big issue), but whats even more worse is that the CMake build failed for me, and thats really bad - you cant just go and build httpd as you do on Linux, no! Your build process is always interupted, and probably as in my case finally broken at all. Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our own makefile, and the build goes through in one go without need for other tools like CMake - just the compiler and probably a platform PDK are enough (and thats how it shoud be). Therefore I want to start a vote here again where we vote for including PCRE again with the dependencies - just as we (now) do with APR/APU; and everyone who votes against should give some good reasons what speaks against -- the fact that every Linux comes with PCRE is certainly no good reason - it only leads finally to the fact that we might end up with 50 builds of httpd 2.after-2.x with different PCE versions which makes then nice bug hunting, and we cant even tell someone who faces a prob to 'use our shipping PCRE which is known to be good'. Here we go: [ ] YES - include recent PCRE again with dependencies (means we create a PCRE repo in svn, check in a recent version, and add platform-dependent makefiles which are fully integrated into main build process). [ ] NO - dont include PCRE (as currently) because of reason: ... thanks, Gün.
Re: Question about APR SHM
Hi Igor, Thanks for the suggestion. I have meanwhile informed the APR developers via the appropriate list. Cheers, Alex Op 08-08-10 21:47, Igor Galić schreef: > - "Alex Wulms" wrote: > > >> Op 31-07-10 18:07, Alex Wulms schreef: >> >>> Hi, >>> > Hi Alex, > > despite the fact that there are a lot of APR developers subscribed to > this list, you're probably better off sending this to > > d...@apr.apache.org > > So long, > >
[PRERELEASE TARBALLS] httpd-2.3.8
The pre-release test tarballs for httpd-2.3.8 (alpha) are available for download, test and fun: http://httpd.apache.org/dev/dist/ Will call for a release vote in a coupla days... Cheers!
Re: [us...@httpd] Windows: Apache 2.2 service ignores shutdown
Sensible suggestion, provided it doesn't cause incompatibility with the previous versions; I'd have to test that. In any case, you were looking for the dev@ list, since this is a suggestion about the httpd code :) On 8/17/2010 12:57 PM, MegaBrutal wrote: > Hello, > > I noticed that after I restart my system, there are signs that Apache > was shut down uncleanly (httpd.pid stays there, error.log doesn't > contain data on exiting). I also see a warning in my error.log, like: > [Tue Aug 17 18:43:06 2010] [warn] pid file C:/Program Files/Apache > Software Foundation/Apache2.2/logs/httpd.pid overwritten -- Unclean > shutdown of previous Apache run? > > Note that I always shut down my computer cleanly. On a clean shutdown, > services should exit cleanly as well, but Apache doesn't. > > Indeed, when I issue an "sc query Apache2.2" command, I see the following: > > SERVICE_NAME: Apache2.2 > TYPE : 10 WIN32_OWN_PROCESS > STATE : 4 RUNNING > (STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN) > WIN32_EXIT_CODE: 0 (0x0) > SERVICE_EXIT_CODE : 0 (0x0) > CHECKPOINT : 0x0 > WAIT_HINT : 0x0 > > It says, the Apache service ignores shutdown - it lets itself > terminated by Windows uncleanly. I've downloaded the source code, and > I've found the problem in /server/mpm/winnt/service.c, in function > "ReportStatusToSCMgr" and "service_nt_ctrl". > > I wouldn't like to mess around and making a patch, so I supply what > would need to be changed here: > > This line in "ReportStatusToSCMgr": > globdat.ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP; > Should be replaced with this: > globdat.ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP | > SERVICE_ACCEPT_PRESHUTDOWN | SERVICE_ACCEPT_SHUTDOWN; > > This line in "service_nt_ctrl": > if (dwCtrlCode == SERVICE_CONTROL_STOP) > Should be replaced with: > if ((dwCtrlCode == SERVICE_CONTROL_STOP) || (dwCtrlCode == > SERVICE_CONTROL_PRESHUTDOWN) || (dwCtrlCode == > SERVICE_CONTROL_SHUTDOWN)) > > NOTE: SERVICE_ACCEPT_PRESHUTDOWN and SERVICE_CONTROL_PRESHUTDOWN are > only supported in Windows Vista and above, however AFAIK earlier > Windows versions just ignore it. So it wouldn't cause compatibility > problems. On Vista & 7, the service would be shut down by a > PRESHUTDOWN; on XP and earlier, it would be shut down by a SHUTDOWN. > If you wouldn't like to use PRESHUTDOWN, it's OK, I just suggest it, > because I noticed that it takes several seconds for Apache to shut > down, so where possible, I'd start it earlier (that's the purpose of > PRESHUTDOWN) to make sure that Apache won't run out of time. > > If you'd really like me to make a patch, then I will, but first I > posted it here - it's just a minor modification, maybe it would be > easier to add for someone who already set up their system to compile > Apache on Windows, and doesn't always forget the proper "diff" command > that makes proper patches. ;) But still, if you don't feel like to do > it, I'll make a patch and also test the feature, if you promise you'd > include it in the next release. > > > Best regards, > MegaBrutal > > > P.S.: Ooops! Sorry, I was a bit outdated. I've just downloaded the > 2.3.6-alpha source code, and I notice you've already added support for > SERVICE_CONTROL_SHUTDOWN. I don't feel like to recompose my e-mail > after all. You could still consider adding SERVICE_CONTROL_PRESHUTDOWN > then. > > - > The official User-To-User support forum of the Apache HTTP Server Project. > See http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >" from the digest: users-digest-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
Re: svn commit: r988483 - /httpd/httpd/branches/2.2.x/STATUS
On 24 Aug 2010, at 12:13, traw...@apache.org wrote: > Author: trawick > Date: Tue Aug 24 11:13:14 2010 > New Revision: 988483 > > URL: http://svn.apache.org/viewvc?rev=988483&view=rev > Log: > fix some bogus rev numbers pointed out by niq My +1 for the 2.2.x patch stands - which is what matters. However: > + http://svn.apache.org/viewvc?rev=986090&view=rev looks to me like another bogus rev: it's not part of this backport proposal and I haven't reviewed it. -- Nick Kew
Re: Plan to T&R 2.3.8
On 24.08.2010 07:56, Ruediger Pluem wrote: On 08/23/2010 06:53 PM, Rainer Jung wrote: On 23.08.2010 15:56, Jim Jagielski wrote: Either today or tomorrow I will be tagging and rolling httpd-2.3.8 Just a head's up. I played a bit with the new http proxy ping. If it is activated and the proxy receives a POST request via HTTP/1.1, it always returns "HTTP/1.1 100 Continue" to the original client, independent of whether the client itself requested this (Expect header set or not) and independent of whether a timeout occured during the backend ping. My thought on Jim's original intention was that this should not happen and that this 100 Continue should be swallowed by the proxy if the proxy added the Expect header. RFC 2616 says in 8.2.3: - An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, ... SHOULD NOT does not sound good. There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100- continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with any other HTTP- version value. This sounds better, but requires us to check that our client sent in a HTTP/1.1 request. When using a 1.0 client (curl -0) I did *not* receive the expectation at the client. S this seems fine. On 23.08.2010 22:33, Jim Jagielski wrote: >> So we don't really break the spec but it could be that some clients might not tolerate any expectation response they haven't asked for. > > Yeah... let's use the release to gain some additional real-world > feedback and then decide whether to rip it out :) I agree. Regards, Rainer
