[
https://issues.apache.org/jira/browse/COUCHDB-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900400#comment-13900400
]
Adam Kocoloski commented on COUCHDB-2059:
-----------------------------------------
Sounds reasonable to me, though I'll note that RFC2616 makes a more stringent
recommendation:
bq. Note: Servers ought to be cautious about depending on URI lengths above 255
bytes, because some older client or proxy implementations might not properly
support these lengths.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1
Not sure any such clients are still in the wild.
> CouchDB replicator sends urls that are too long for comfort
> -----------------------------------------------------------
>
> Key: COUCHDB-2059
> URL: https://issues.apache.org/jira/browse/COUCHDB-2059
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Replication
> Reporter: Isaac Z. Schlueter
> Fix For: 1.7.0
>
>
> I have my couchdb behind an TLS terminator. Like most HTTP servers, it has a
> limit on how long URLs can be, and that limit is far smaller than the 6-12KB
> urls that the CouchDB replicator is sending.
> https://gist.github.com/isaacs/0010221834a3491d6481
> http://cl.ly/image/3N192G293j1R
> This is a bug, right?
> For added frustration:
> 1. The replication never goes into a failed state. Just stays "triggered"
> forever, doing nothing, hung at 77%.
> 2. The logs are indented with over 6000 spaces. I've been known to do some
> crazy code formatting in my time, but this is too extreme, and makes reading
> the log unnecessarily difficult.
> Suggestion:
> Limit the length of URLs that the replicator will use to something more
> reasonable, such as 1024 bytes. If more data than that is required, send it
> in the body of the request.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
