Hi all, I''m having a problem with Rails'' Subversion server. Attempts to mirror/synchronize Rails Subversion or simply doing this: ceefour> svn log -v http://svn.rubyonrails.org/rails/trunk svn: REPORT request failed on ''/rails/!svn/bc/7513/trunk'' svn: REPORT of ''/rails/!svn/bc/7513/trunk'': Response exceeded maximum number of header fields. (http://svn.rubyonrails.org) ceefour> svn --version svn, version 1.4.3 (r23084) compiled Mar 28 2007, 22:48:32 Copyright (C) 2000-2006 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles ''http'' scheme - handles ''https'' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles ''svn'' scheme * ra_local : Module for accessing a repository on local disk. - handles ''file'' scheme Resulted in the above error. Is this a known problem? This error is reproducible on any system. Thank you. -- Hendy Irawan www.hendyirawan.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/19/07, Hendy Irawan <gauldong@gmail.com> wrote:> > > ceefour> svn log -v http://svn.rubyonrails.org/rails/trunk > svn: REPORT request failed on ''/rails/!svn/bc/7513/trunk'' > svn: REPORT of ''/rails/!svn/bc/7513/trunk'': Response exceeded maximum > number of header fields. (http://svn.rubyonrails.org)Umm ... try it with "--limit N". Otherwise you''ll be requesting the whole svn log of Rails trunk, verbosely. I don''t know how the Apache svn_dav module uses HTTP headers, but with such huge data you''re bound to have "something exceeded maximum something" errors. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
While diagnosing this problem with Jelmer Vernooij (Bazaar), it seems that there is a certain "misconfiguration" on the part of Rails Subversion server hosted on Joyent. If this is a Joyent-side issue, would someone with authority of the Rails SVN server please contact Joyent about this problem so we can resolve it? Thank you. -------- Original Message -------- Subject: Re: Attn: Jelmer & David (was [Fwd: [Rails-core] Re: ERROR on Rails Subversion repository]) Date: Wed, 19 Sep 2007 15:46:07 +0200 From: Jelmer Vernooij <jelmer@samba.org> To: Hendy Irawan <hendy@rainbowpurple.com> CC: Bazaar Mailing List <bazaar@lists.canonical.com> References: <46F1066B.7030703@rainbowpurple.com> Hi Hendy, Am Mittwoch, den 19.09.2007, 18:22 +0700 schrieb Hendy Irawan:> Although I''m not sure about the exact culprit, there is possibility > that this happens not only on Rails SVN server, but also a bunch of > other SVN servers in the world. Be it misconfigured, having an old > version of library, or something.If this is not a configuration issue, it should ideally be fixed in the Subversion client library so that all users of libsvn can benefit from it.> From the description, and from experiments, it seems true that > limiting does have the "nice" effect of avoiding these errors, which > means that can probably do a workaround. > > My proposal is that bzr-svn will issue "svn log -v" in bulk batches, > i.e. 1000 revisions at once. If it can work out, then it should work > more reliably with "buggy" SVN servers. And the running performance > shouldn''t be that bad. Considering that even in a 10,000 revisions > repository, we''ll only do that 10 times. And that is still better than > try to do that once, and fail. :-(Limiting the number of revisions fetched to a 1000 per time still causes this error. Anything over 600 seems to break, which seems rather arbitrary. I also bet that if there are long commit messages that it breaks even earlier.> I''ll also try joining the Subversion list to see if anyone comes up > with a better solution. But even if Subversion will have a fix in the > future, there''s no guarantee that everyone in the world will be > rushing to update it... So a workaround is still needed > unfortunately. :-(I''m not sure this is a misconfiguration in the Subversion side of things. The rubyonrails server returns the following headers when I run `svn log'': HTTP/1.1 200 OK Date: Wed, 19 Sep 2007 13:27:54 GMT Server: Apache Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent Served-By: Joyent MS-Author-Via: DAV Vary: Accept-Encoding Content-Encoding: gzip MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV MS-Author-Via: DAV Connection: close Transfer-Encoding: chunked Content-Type: text/xml; charset="utf-8" Notice that MS-Author-Via: DAV and Served-By: Joyent are repeated. It almost seems like it''s adding a new header for every x kilobytes of data or something that is returned. Requesting 1000 revisions results in these two headers being repeated 48 times, whereas requesting 500 revisions results in them being repeated 26 times. I don''t want to degrade the performance of bzr-svn to work around a single SVN repository with a broken configuration, but I can live with a knob that allows setting the number of revisions fetched with svn.ra.get_log(). Cheers, Jelmer -- Jelmer Vernooij <jelmer@samba.org> - http://samba.org/~jelmer/ Jabber: jelmer@jabber.fsfe.org -- Hendy Irawan www.hendyirawan.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Hendy,
There aren''t any configurations to do with SVN other than turning it
on. What''s happening is no different than standard HTTP errors when
you''re trying to push or pull too much stuff. No different then trying
to put a string that''s over 1024 bytes into IE, or trying to pass a
string that''s larger to 4096 bytes to Apache (so something like
passing 200 facebook "friends" IDs in a string.)
Yes, I see the same thing with pulling up a PATH on the URL of the svn
repository
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails trunk
svn: REPORT request failed on ''/rails/!svn/bc/7514''
svn: REPORT of ''/rails/!svn/bc/7514'': Response exceeded
maximum number
of header fields. (http://svn.rubyonrails.org)
The error isn''t from subversion it''s from the Neon library
that
subversion uses for http and webdav access to stuff.
In ne_request.c, the max header is 8192 bytes
#define MAX_HEADER_LEN (8192)
/* Read response headers. Returns NE_* code, sets session error and
* closes connection on error. */
static int read_response_headers(ne_request *req)
{
char hdr[MAX_HEADER_LEN];
int ret, count = 0;
while ((ret = read_message_header(req, hdr, sizeof hdr)) =NE_RETRY
&& ++count < MAX_HEADER_FIELDS) {
char *pnt;
unsigned int hash = 0;
/* Strip any trailing whitespace */
pnt = hdr + strlen(hdr) - 1;
while (pnt > hdr && (*pnt == '' '' || *pnt ==
''\t''))
*pnt-- = ''\0'';
/* Convert the header name to lower case and hash it. */
for (pnt = hdr; (*pnt != ''\0'' && *pnt !=
'':'' &&
*pnt != '' '' && *pnt != ''\t'');
pnt++) {
*pnt = ne_tolower(*pnt);
hash = HH_ITERATE(hash,*pnt);
}
/* Skip over any whitespace before the colon. */
while (*pnt == '' '' || *pnt == ''\t'')
*pnt++ = ''\0'';
/* ignore header lines which lack a '':''. */
if (*pnt != '':'')
continue;
/* NUL-terminate at the colon (when no whitespace before) */
*pnt++ = ''\0'';
/* Skip any whitespace after the colon... */
while (*pnt == '' '' || *pnt == ''\t'')
pnt++;
/* pnt now points to the header value. */
NE_DEBUG(NE_DBG_HTTP, "Header Name: [%s], Value: [%s]\n", hdr, pnt);
add_response_header(req, hash, hdr, pnt);
}
if (count == MAX_HEADER_FIELDS)
ret = aborted(
req, _("Response exceeded maximum number of header fields"), 0);
return ret;
}
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails trunk
svn: REPORT request failed on ''/rails/!svn/bc/7514''
svn: REPORT of ''/rails/!svn/bc/7514'': Response exceeded
maximum number
of header fields. (http://svn.rubyonrails.org)
Jasons-15er% svn log -v http://svn-commit.rubyonrails.org/rails trunk
| wc -l
46380
So let''s take a look and see
Nonverbose is fine
Jasons-15er% svn log http://svn.rubyonrails.org/rails trunk | wc -l
23132
Oddly enough, verbose on the entire repos URL is also fine (leave off
trunk) ... try and figure out that one
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails | wc -l
66627
Verbose on a specific version is fine
Jasons-15er% svn log -v -r 7000 http://svn.rubyonrails.org/rails
trunk
------------------------------------------------------------------------
r7000 | bitsweat | 2007-06-11 10:06:07 +0200 (Mon, 11 Jun 2007) | 1
line
Changed paths:
M /trunk/activerecord/lib/active_record/base.rb
Remove deprecated quote methods, replaced by quote_value so quote can
be used as an attribute name.
------------------------------------------------------------------------
Verbose in a range of 1000 is fine
Jasons-15er% svn log -v -r 1000:2000 http://svn.rubyonrails.org/rails
trunk | wc -l
7205
Let''s now extend that range, the above is 1000, let''s keep
increasing
that by 1000 until it "breaks" again
Jasons-15er% svn log -v -r 1:2000 http://svn.rubyonrails.org/rails
trunk | wc -l
svn: REPORT request failed on ''/rails/!svn/bc/2000''
svn: REPORT of ''/rails/!svn/bc/2000'': Response exceeded
maximum number
of header fields. (http://svn.rubyonrails.org)
0
And yes the breakpoint is the size of the header fields coming back.
Let''s turn the extraneous headers off-and-on.
It turns out to be the standard Header add MS-Author-Via "DAV" that
one adds in (and used to be a DAV default) for some window''s clients.
header being sent
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk
svn: REPORT request failed on ''/rails/!svn/bc/7514/trunk''
svn: REPORT of ''/rails/!svn/bc/7514/trunk'': Response exceeded
maximum
number of header fields. (http://svn.rubyonrails.org)
header off
Jasons-15er% svn log -v http://svn-commit.rubyonrails.org/rails/trunk
| wc -l
46380
header being sent
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk
svn: REPORT request failed on ''/rails/!svn/bc/7514/trunk''
svn: REPORT of ''/rails/!svn/bc/7514/trunk'': Response exceeded
maximum
number of header fields. (http://svn.rubyonrails.org)
header off
Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk | wc -l
46380
The header is off (and for reference one can just turn off mod_headers
entirely) and should be fine now.
Regards, Jason
On Sep 19, 3:57 pm, Hendy Irawan <gauld...@gmail.com>
wrote:> While diagnosing this problem with Jelmer Vernooij (Bazaar), it seems
> that there is a certain "misconfiguration" on the part of Rails
> Subversion server hosted on Joyent.
>
> If this is a Joyent-side issue, would someone with authority of the
> Rails SVN server please contact Joyent about this problem so we can
> resolve it?
>
> Thank you.
>
> -------- Original Message --------
> Subject: Re: Attn: Jelmer & David (was [Fwd: [Rails-core] Re:
ERROR on
>
> Rails Subversion repository])
> Date: Wed, 19 Sep 2007 15:46:07 +0200
> From: Jelmer Vernooij <jel...@samba.org>
> To: Hendy Irawan <he...@rainbowpurple.com>
> CC: Bazaar Mailing List <baz...@lists.canonical.com>
> References: <46F1066B.7030703@rainbowpurple.com>
>
> Hi Hendy,
>
> Am Mittwoch, den 19.09.2007, 18:22 +0700 schrieb Hendy Irawan:
> > Although I''m not sure about the exact culprit, there is
possibility
> > that this happens not only on Rails SVN server, but also a bunch of
> > other SVN servers in the world. Be it misconfigured, having an old
> > version of library, or something.
> If this is not a configuration issue, it should ideally be fixed in the
> Subversion client library so that all users of libsvn can benefit from
> it.
>
> > From the description, and from experiments, it seems true that
> > limiting does have the "nice" effect of avoiding these
errors, which
> > means that can probably do a workaround.
>
> > My proposal is that bzr-svn will issue "svn log -v" in bulk
batches,
> > i.e. 1000 revisions at once. If it can work out, then it should work
> > more reliably with "buggy" SVN servers. And the running
performance
> > shouldn''t be that bad. Considering that even in a 10,000
revisions
> > repository, we''ll only do that 10 times. And that is still
better than
> > try to do that once, and fail. :-(
> Limiting the number of revisions fetched to a 1000 per time still causes
> this error. Anything over 600 seems to break, which seems rather
> arbitrary. I also bet that if there are long commit messages that it
> breaks even earlier.
>
> > I''ll also try joining the Subversion list to see if anyone
comes up
> > with a better solution. But even if Subversion will have a fix in the
> > future, there''s no guarantee that everyone in the world will
be
> > rushing to update it... So a workaround is still needed
> > unfortunately. :-(
> I''m not sure this is a misconfiguration in the Subversion side of
> things. The rubyonrails server returns the following headers when I run
> `svn log'':
>
> HTTP/1.1 200 OK
> Date: Wed, 19 Sep 2007 13:27:54 GMT
> Server: Apache
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> Served-By: Joyent
> MS-Author-Via: DAV
> Vary: Accept-Encoding
> Content-Encoding: gzip
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> MS-Author-Via: DAV
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/xml; charset="utf-8"
>
> Notice that MS-Author-Via: DAV and Served-By: Joyent are repeated.
>
> It almost seems like it''s adding a new header for every x
kilobytes of
> data or something that is returned. Requesting 1000 revisions results in
> these two headers being repeated 48 times, whereas requesting 500
> revisions results in them being repeated 26 times.
>
> I don''t want to degrade the performance of bzr-svn to work around
a
> single SVN repository with a broken configuration, but I can live with a
> knob that allows setting the number of revisions fetched with
> svn.ra.get_log().
>
> Cheers,
>
> Jelmer
> --
> Jelmer Vernooij <jel...@samba.org> -http://samba.org/~jelmer/
> Jabber: jel...@jabber.fsfe.org
>
> --
> Hendy Irawanwww.hendyirawan.com
>
>
>
> signature.asc
> 1KDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
jason wrote:> Hi Hendy, > > There aren''t any configurations to do with SVN other than turning it > on. What''s happening is no different than standard HTTP errors when > you''re trying to push or pull too much stuff. No different then trying > to put a string that''s over 1024 bytes into IE, or trying to pass a > string that''s larger to 4096 bytes to Apache (so something like > passing 200 facebook "friends" IDs in a string.) > > Yes, I see the same thing with pulling up a PATH on the URL of the svn > repository > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails trunk > svn: REPORT request failed on ''/rails/!svn/bc/7514'' > svn: REPORT of ''/rails/!svn/bc/7514'': Response exceeded maximum number > of header fields. (http://svn.rubyonrails.org) > > The error isn''t from subversion it''s from the Neon library that > subversion uses for http and webdav access to stuff. > > In ne_request.c, the max header is 8192 bytes > > #define MAX_HEADER_LEN (8192) > > /* Read response headers. Returns NE_* code, sets session error and > * closes connection on error. */ > static int read_response_headers(ne_request *req) > { > char hdr[MAX_HEADER_LEN]; > int ret, count = 0; > > while ((ret = read_message_header(req, hdr, sizeof hdr)) => NE_RETRY > && ++count < MAX_HEADER_FIELDS) { > char *pnt; > unsigned int hash = 0; > > /* Strip any trailing whitespace */ > pnt = hdr + strlen(hdr) - 1; > while (pnt > hdr && (*pnt == '' '' || *pnt == ''\t'')) > *pnt-- = ''\0''; > > /* Convert the header name to lower case and hash it. */ > for (pnt = hdr; (*pnt != ''\0'' && *pnt != '':'' && > *pnt != '' '' && *pnt != ''\t''); pnt++) { > *pnt = ne_tolower(*pnt); > hash = HH_ITERATE(hash,*pnt); > } > > /* Skip over any whitespace before the colon. */ > while (*pnt == '' '' || *pnt == ''\t'') > *pnt++ = ''\0''; > > /* ignore header lines which lack a '':''. */ > if (*pnt != '':'') > continue; > > /* NUL-terminate at the colon (when no whitespace before) */ > *pnt++ = ''\0''; > > /* Skip any whitespace after the colon... */ > while (*pnt == '' '' || *pnt == ''\t'') > pnt++; > > /* pnt now points to the header value. */ > NE_DEBUG(NE_DBG_HTTP, "Header Name: [%s], Value: [%s]\n", hdr, pnt); > add_response_header(req, hash, hdr, pnt); > } > > if (count == MAX_HEADER_FIELDS) > ret = aborted( > req, _("Response exceeded maximum number of header fields"), 0); > > return ret; > } > > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails trunk > svn: REPORT request failed on ''/rails/!svn/bc/7514'' > svn: REPORT of ''/rails/!svn/bc/7514'': Response exceeded maximum number > of header fields. (http://svn.rubyonrails.org) > Jasons-15er% svn log -v http://svn-commit.rubyonrails.org/rails trunk > | wc -l > 46380 > > So let''s take a look and see > > Nonverbose is fine > > Jasons-15er% svn log http://svn.rubyonrails.org/rails trunk | wc -l > 23132 > > Oddly enough, verbose on the entire repos URL is also fine (leave off > trunk) ... try and figure out that one > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails | wc -l > 66627 > > Verbose on a specific version is fine > > Jasons-15er% svn log -v -r 7000 http://svn.rubyonrails.org/rails > trunk > ------------------------------------------------------------------------ > r7000 | bitsweat | 2007-06-11 10:06:07 +0200 (Mon, 11 Jun 2007) | 1 > line > Changed paths: > M /trunk/activerecord/lib/active_record/base.rb > > Remove deprecated quote methods, replaced by quote_value so quote can > be used as an attribute name. > ------------------------------------------------------------------------ > > Verbose in a range of 1000 is fine > > Jasons-15er% svn log -v -r 1000:2000 http://svn.rubyonrails.org/rails > trunk | wc -l > 7205 > > Let''s now extend that range, the above is 1000, let''s keep increasing > that by 1000 until it "breaks" again > > Jasons-15er% svn log -v -r 1:2000 http://svn.rubyonrails.org/rails > trunk | wc -l > svn: REPORT request failed on ''/rails/!svn/bc/2000'' > svn: REPORT of ''/rails/!svn/bc/2000'': Response exceeded maximum number > of header fields. (http://svn.rubyonrails.org) > 0 > > And yes the breakpoint is the size of the header fields coming back. > > Let''s turn the extraneous headers off-and-on. > > It turns out to be the standard Header add MS-Author-Via "DAV" that > one adds in (and used to be a DAV default) for some window''s clients. > > header being sent > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk > svn: REPORT request failed on ''/rails/!svn/bc/7514/trunk'' > svn: REPORT of ''/rails/!svn/bc/7514/trunk'': Response exceeded maximum > number of header fields. (http://svn.rubyonrails.org) > > header off > > Jasons-15er% svn log -v http://svn-commit.rubyonrails.org/rails/trunk > | wc -l > 46380 > > header being sent > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk > svn: REPORT request failed on ''/rails/!svn/bc/7514/trunk'' > svn: REPORT of ''/rails/!svn/bc/7514/trunk'': Response exceeded maximum > number of header fields. (http://svn.rubyonrails.org) > > header off > > Jasons-15er% svn log -v http://svn.rubyonrails.org/rails/trunk | wc -l > > 46380 > > The header is off (and for reference one can just turn off mod_headers > entirely) and should be fine now. > > Regards, Jason > > >Thank you very much Jason...! It seems all to work fine now... :-) As a side note, I''m not sure how mod_headers and DAV internally works, but to me sending repeated, exact duplicate headers for numerous number of times (up to the number of retrieved revisions?) seems a bit too redundant.... especially considering bandwidth isn''t that cheap... But I''m not in the position to criticize this... I don''t even know how it works. Again, thanks Jason, and thank you Joyent :) -- Hendy Irawan www.hendyirawan.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I am sorry I am not sure how turn the header off. Is this in Apache? thanks -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I for one am glad rails has avoided threading, but find the multi- mongrel approach a little lacking. As a twisted python user, I find the asynch approach far superior to threading for network tasks. Twisted apps I have built handle tens of thousands of requests per second. An example in ruby would be resizing an image stored on s3 - the twisted way is to launch the http get, then add a callback that gets invoked when the download is complete, thus allowing the server to serve many other requests in the meantime. Anyone else thinking in this direction? M Sent from my iPhone On Apr 2, 2008, at 9:06 AM, Pavel Pragin <ruby-forum-incoming@andreas-s.net > wrote:> > I am sorry I am not sure how turn the header off. Is this in Apache? > thanks > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Apr 2, 2008 at 9:43 AM, Marc Byrd <dr.marc.byrd@gmail.com> wrote:> > I for one am glad rails has avoided threading, but find the multi- > mongrel approach a little lacking. As a twisted python user, I find > the asynch approach far superior to threading for network tasks. > Twisted apps I have built handle tens of thousands of requests per > second. > > An example in ruby would be resizing an image stored on s3 - the > twisted way is to launch the http get, then add a callback that gets > invoked when the download is complete, thus allowing the server to > serve many other requests in the meantime. > > Anyone else thinking in this direction?I remember Twisted Python being really cool back in my Python days (even met a committer at a lan party one, heh). I think the thing to do would be to create a similar ruby web server that supports the Rack interface. That''s the approach taken with other projects like Thin and Ebb: both of which look really cool. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---