From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80540 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-sync.el v2 Date: Sun, 06 Nov 2011 09:07:50 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wrbdl4y1.fsf@lifelogs.com> References: <87mxcv3fu2.fsf@lifelogs.com> <87pqhicp6m.fsf@lifelogs.com> <87wrbqb4u8.fsf@lifelogs.com> <87lirw7w1d.fsf@dod.no> <8739e4q3uo.fsf@lifelogs.com> <87fwi47ryn.fsf@dod.no> <87obwsnkqv.fsf@lifelogs.com> <877h3f7gqk.fsf@dod.no> <87r51nmvr5.fsf@lifelogs.com> <87zkgb57kt.fsf@dod.no> <87mxcanbcv.fsf@lifelogs.com> <87vcqy6e59.fsf@dod.no> <87fwi2n2pt.fsf@lifelogs.com> <87mxca5uip.fsf@dod.no> <871utm5ree.fsf@dod.no> <87ty6i4c8u.fsf@dod.no> <87pqh649yk.fsf@dod.no> <877h3e5o22.fsf@topper.koldfront.dk> <87liru43q4.fsf@dod.no> <871utlmm0c.fsf@lifelogs.com> <87d3d54bno.fsf@dod.no> Reply-To: ding@gnus.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1320588494 17966 80.91.229.12 (6 Nov 2011 14:08:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Nov 2011 14:08:14 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M28823=ding+2Daccount=gmane.org@lists.math.uh.edu Sun Nov 06 15:08:10 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RN3OL-0000t5-Qm for ding-account@gmane.org; Sun, 06 Nov 2011 15:08:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1RN3OL-0005Uc-3E for ding-account@gmane.org; Sun, 06 Nov 2011 08:08:09 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1RN3OI-0005UT-LK for ding@lists.math.uh.edu; Sun, 06 Nov 2011 08:08:06 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RN3OH-0002ox-E2 for ding@lists.math.uh.edu; Sun, 06 Nov 2011 08:08:06 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1RN3OG-0007Hn-08 for ding@gnus.org; Sun, 06 Nov 2011 15:08:04 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RN3OE-0000o7-Mv for ding@gnus.org; Sun, 06 Nov 2011 15:08:02 +0100 Original-Received: from c-76-28-40-19.hsd1.vt.comcast.net ([76.28.40.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Nov 2011 15:08:02 +0100 Original-Received: from tzz by c-76-28-40-19.hsd1.vt.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Nov 2011 15:08:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 53 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-40-19.hsd1.vt.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:wdcoahUV02rcvKURzBgF3tgiRpI= X-Spam-Score: -6.1 (------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80540 Archived-At: On Sun, 06 Nov 2011 14:34:51 +0100 Steinar Bang wrote: >>>>>> Ted Zlatanov : >> I thought json.el would handle this but apparently it doesn't to >> CouchDB's satisfaction; the JSON may indeed be valid. SB> Actually CouchDB is quite comfortable with the JSON generated, as long SB> as it gets all of it. See my experiments with feeding that JSON SB> directly to CouchDB using curl. Oh I see. OK. SB> Looking at the code you use to send off the http request, ie. SB> #+begin_src lisp SB> ... SB> (let ((url-request-method method) SB> (url-request-extra-headers headers) SB> (url-request-data (if kvdata (json-encode kvdata) nil))) SB> (with-current-buffer (url-retrieve-synchronously url) SB> ... SB> #+end_src SB> the setting of content-length is left to url-retrieve-synchronously, and SB> it is that code that fails...? >> I will try to fix this (or someone else can do it if they feel frisky, >> see `json-encode-char' and `json-read-escaped-char'). SB> Hm... thoses are ok I think. But it looks like Adam was right and that SB> url-retrieve and friends, set content-length from the number of SB> characters in the data they are trying to send. And that's actually a SB> bug in that function, which apparently is present in emacs24 snapshots. SB> Content-Length should be in bytes. SB> I guess someone should report it...? :-) That's work! No way! Oh, OK. `url-http-create-request' says: (if url-http-data (concat "Content-length: " (number-to-string (length url-http-data)) "\r\n")) which seems reasonable to me (the JSON data at that point contains only the escaped characters). Can you log `url-http-data' at that point for your case? Or maybe make a test case that fails? I won't be able to look at this until later, and a reproducible test case is the nicest way to submit a bug report. Thanks Ted