Subject: Re: [Tools-discuss] [www.ietf.org/rt #115169] Data tracker API failing with 'Internal Server Error'

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 14 Mar 2016 14:59:00 +0000

The API to IETF data is still failing, just like it was a week ago. What is the plan for getting this fixed?

104:fred@irp-lnx1% date;curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg'
Mon Mar 14 07:56:14 PDT 2016
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>504 Gateway Timeout</title>
</head><body>
<h1>Gateway Timeout</h1>
<p>The gateway did not receive a timely response
from the upstream server or application.</p>
</body></html>

> On Mar 10, 2016, at 1:06 PM, Fred Baker (fred) <[email-masked]> wrote:
> 
> Would it help if I sent my script, perhaps? See attached. My model command is:
> 
> perl -w json-cisco-work.pl --wg --individual --debug test current > cisco-drafts.txt
> 
> You will need to change one access, which seeks to read http://wwwin-people.cisco.com/fred/cisco_exceptions; you can't get to it from outside Cisco. I have attached it as a file.
> 
> The debug option has it say what it is trying to read, giving you the option of repeating the access. In the output following, you will notice that it correctly accessed
> 
> "current" is a list of active internet drafts, derived from 1id-index.txt.
> 
> I ran the script twice, and got different results - something that has been an issue all through this. It seems to be able to correctly access a random number of json files, and then has some issue (in this case, "404 no such file", in other cases a gateway failure or an internal error) on which it chokes.
> 
> Note that this all worked until recently. This is not new code.
> 
> 119:fred@irp-lnx1% !nice
> nice csh /users/fred/WWW/json/new-work.sh 2015-10-20 2015-11-01 2016-03-27 November-March-2016
> accessing http://wwwin-people.cisco.com/fred/cisco_exceptions
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-rfceditor' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ise' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-iesg' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ietf' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=ietf' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=area' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg' 2> /dev/null
> malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at json-cisco-new-work.pl line 171
> accessing http://wwwin-people.cisco.com/fred/cisco_exceptions
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-rfceditor' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ise' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-iesg' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ietf' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=ietf' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=area' 2> /dev/null
> accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg' 2> /dev/null
> malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at json-cisco-new-work.pl line 171
> 120:fred@irp-lnx1% date;curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg'
> Thu Mar 10 12:23:27 PST 2016
> 
> <!DOCTYPE html>
> 
> 
> 
> <html lang="en">
>  <head>
>    <meta charset="utf-8">
>    <meta http-equiv="X-UA-Compatible" content="IE=edge">
>    <title>404 Not Found</title>
>    <meta name="viewport" content="width=device-width, initial-scale=1">
> 
>    <link href="https://www.ietf.org/lib/dt/6.16.0/ptmono/stylesheet.css" rel='stylesheet' type='text/css'>
>    <link href="https://www.ietf.org/lib/dt/6.16.0/ptsans/stylesheet.css" rel='stylesheet' type='text/css'>
>    <link href="https://www.ietf.org/lib/dt/6.16.0/ptserif/stylesheet.css" rel='stylesheet' type='text/css'>
> 
> ...
> 
> 
>> On Mar 10, 2016, at 12:12 PM, Matt Larson via RT <[email-masked]> wrote:
>> 
>> Hi Fred,
>> 
>> We've done some further tuning, and believe that this is resolved. Please let
>> me know if you have any further issues.
>> 
>> Matt
>> 
>> On Thu Mar 10 09:44:29 2016, [email-masked] wrote:
>>> 
>>>> On Mar 10, 2016, at 5:21 AM, Matt Larson via RT <ietf-
>>> [email-masked]> wrote:
>>>> 
>>>> Greetings,
>>>> 
>>>> I believe this has stabilized now that the server move is completed.
>>> I did some
>>>> testing and have been able to consistently pull that URL, along with
>>> a sampling
>>>> of the others.
>>>> 
>>>> I am going to resolve out this ticket, but please let us know if
>>> there are any
>>>> further issues. Replying to this email will re-open the ticket.
>>>> 
>>>> Matt
>>> 
>>> 105:fred@irp-lnx1% nice perl -w /users/fred/WWW/json/json-cisco-
>>> work.pl --wg --individual --debug test /users/fred/draft/.current >
>>> /users/fred/WWW/json/cisco-drafts.txt
>>> accessing http://wwwin-people.cisco.com/fred/cisco_exceptions
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>> rfceditor' 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>> stream-ise' 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>> iesg' 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>> stream-ietf' 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=ietf'
>>> 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=area'
>>> 2> /dev/null
>>> accessing curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg'
>>> 2> /dev/null
>>> malformed JSON string, neither array, object, number, string or atom,
>>> at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at
>>> /users/fred/WWW/json/json-cisco-work.pl line 177
>>> 106:fred@irp-lnx1% date;curl
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg'
>>> Thu Mar 10 09:43:38 PST 2016
>>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>> <html><head>
>>> <title>504 Gateway Timeout</title>
>>> </head><body>
>>> <h1>Gateway Timeout</h1>
>>> <p>The gateway did not receive a timely response
>>> from the upstream server or application.</p>
>>> </body></html>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Tue Mar 08 22:16:23 2016, [email-masked] wrote:
>>>>> Over the past few days (at least, I'm not sure when it started
>>>>> happening) I am randomly getting errors that look like this. Often
>>>>> several - tens or hundreds - of transactions will work and then one
>>>>> fail.
>>>>> 
>>>>> Suggestions?
>>>>> 
>>>>> 144:fred@irp-lnx1% curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg'
>>>>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>>>> <html><head>
>>>>> <title>500 Internal Server Error</title>
>>>>> </head><body>
>>>>> <h1>Internal Server Error</h1>
>>>>> <p>The server encountered an internal error or
>>>>> misconfiguration and was unable to complete
>>>>> your request.</p>
>>>>> <p>Please contact the server administrator at
>>>>> [email-masked] to inform them of the time this error
>>> occurred,
>>>>> and the actions you performed just before this error.</p>
>>>>> <p>More information about this error may be available
>>>>> in the server error log.</p>
>>>>> <p>Additionally, a 403 Forbidden
>>>>> error was encountered while trying to use an ErrorDocument to
>>> handle
>>>>> the request.</p>
>>>>> </body></html>
>>>>> 
>>>>> 
>>>>> My models, in case this is relevant:
>>>>> 
>>>>> 145:fred@irp-lnx1% fgrep datatracker.ietf.org
>>>>> /users/fred/WWW/json/json-cisco-work.pl
>>>>> "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>>>> stream-ietf' 2> /dev/null";
>>>>> "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>>>> iesg' 2> /dev/null";
>>>>> "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>>>> rfceditor' 2> /dev/null";
>>>>> $curl_ise_rev = "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-
>>>>> stream-ise' 2> /dev/null";
>>>>> "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/group/group/\?format=json&limit=0&type__slug__in=%s'
>>>>> 2> /dev/null";
>>>>> my $curl = "curl 'https://datatracker.ietf.org%s?format=json' 2>
>>>>> /dev/null";
>>>>> "curl
>>>>> 
>>>> 
>>> 
>> 'https://datatracker.ietf.org/api/v1/doc/document/\?format=json\&name__contains=%s\&limit=0'
>>>>> 2> /dev/null";
>>>>> "curl 'https://datatracker.ietf.org%s\?format=json' 2>
>>>>> /dev/null";
> 
> <json-cisco-work.pl><current><cisco_exceptions>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Mar 2016 18:49:30 +0100

Hi Fred,

You may already have seen the blurb for the latest datatracker release,
but in case not, I've introduced some caching which should reduce the
time it takes to produce REST API responses:

   https://datatracker.ietf.org/release/6.17.0/

It turns out that the API framework we are using has a weakness in how
it deals with related objects, and this caused a doubling (approximately)
of the response time for the groups query, even if the new related objects
were 2 relationships away.  The caching I've coded up should deal with this,
and my tests indicate an improvement with about a factor 4, or a factor 2
better than before 6.16.0.

If, however, things still aren't working out for you, please let Glen,
Robert and me know.

Best regards,

	Henrik

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 16 Mar 2016 18:46:21 +0000

Thanks.

Copying Glen, who has been working on this. Last week, there were a number of more-or-less-random failures, including server errors, gateways that were unreachable, and files not found. In the past couple of days, Glen has taken a look at it, and appears to have mostly resolved the issues. I have one remaining issue, which I'm tracking down as we speak so I can describe it to Glen. It goes something like this.

I have two scripts that I'm looking at. One wonders what drafts Cisco employees have in the pipeline (so we can inform various communities inside the company); the other wonders what subset of those have been updated since the past IETF meeting and are specifically working group draft, or are specifically individual submissions (because we get asked). Note that one of the two seems to invariably work, and is accessing essentially the same data. The script that asks about the more general set of drafts seems to mostly work, downloading state information etc and then moving on to downloading relevant draft metadata (I'd download the entire set of drafts in one swell foop, but there are more than 1000 drafts at any given time). I see this:

First, quite a number of perfectly normal and successful accesses (I'm showing you my debug output, which says what command I'm executing):

perl -w /users/fred/WWW/json/json-cisco-work.pl --wg --debug test --individual /users/fred/draft/.current > /users/fred/WWW/json/cisco-drafts.txt
accessing http://wwwin-people.cisco.com/fred/cisco_exceptions
accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-rfceditor' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ise' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-iesg' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/?format=json&limit=0&type__slug__in=draft-stream-ietf' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=ietf' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=area' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=wg' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=irtf' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=rg' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=ag' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=iab' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/group/group/?format=json&limit=0&type__slug__in=dir' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-ietf-insipid-logme-reqs&limit=0' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/state/1/?format=json' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-li-pce-tunnel-segment&limit=0' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-urien-core-racs&limit=0' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-ietf-avtcore-rtp-multi-stream-optimisation&limit=0' 2> /dev/null
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-ietf-tcpm-accurate-ecn&limit=0' 2> /dev/null

I see probably 500 or more accesses for internet draft metadata similar to that last line, but for various drafts. And then I see:

accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-irtf-cfrg-xmss-hash-based-signatures&limit=0' 2> /dev/null
JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at /users/fred/WWW/json/json-cisco-work.pl line 256

Note that this doesn't happen on any specific draft, just on some draft whose metadata I access. When I get curious about what it accessed, I get:

121:fred@irp-lnx1% curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name__contains=draft-irtf-cfrg-xmss-hash-based-signatures&limit=0'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
{"meta": {"limit": 1000, "next": null, "offset": 0, "previous": null, "total_count": 1}, "objects": [{"abstract": "   This note describes the eXtended Merkle Signature Scheme (XMSS), a\n   hash-based digital signature system.  It follows existing\n   descriptions in scientific literature.  The note specifies the WOTS+\n   one-time signature scheme, a single-tree (XMSS) and a multi-tree\n   variant (XMSS^MT) of XMSS.  Both variants use WOTS+ as a main\n   building block.  XMSS provides cryptographic digital signatures\n   without relying on the conjectured hardness of mathematical problems.\n   Instead, it is proven that it only relies on the properties of\n   cryptographic hash functions.  XMSS provides strong security\n   guarantees and, besides some special instantiations, is even secure\n   when the collision resistance of the underlying hash function is\n   broken.  It is suitable for compact implementations, relatively\n   simple to implement, and naturally resists side-channel attacks.\n   Unlike most o105  1997  105  1997    0     0    142      0  0:00:14  0:00:13  0:00:01   410
ther signature systems, hash-based signatures withstand\n   attacks using quantum computers.\n", "ad": null, "authors": ["/api/v1/person/email/dbutin%40cdc.informatik.tu-darmstadt.de/", "/api/v1/person/email/stefan-lukas_gazdag%40genua.eu/", "/api/v1/person/email/ietf%40huelsing.net/", "/api/v1/person/email/mohaisen%40buffalo.edu/"], "expires": "2016-08-18T03:54:01", "external_url": "", "group": "/api/v1/group/group/1969/", "intended_std_level": null, "internal_comments": "", "name": "draft-irtf-cfrg-xmss-hash-based-signatures", "note": "", "notify": "", "order": 1, "pages": 56, "resource_uri": "/api/v1/doc/document/draft-irtf-cfrg-xmss-hash-based-signatures/", "rev": "03", "rfc": null, "shepherd": null, "states": ["/api/v1/doc/state/1/", "/api/v1/doc/state/58/"], "std_level": null, "stream": "/api/v1/name/streamname/ietf/", "tags": [], "time": "2016-02-15T03:54:01", "title": "XMSS: Extended Hash-Based Signatures", "type": "/api/v1/name/doctypename/draft/"}]}122:fred@irp-lnx1%

Which is to say that the json response is just fine, thank you very much.

What I conclude (what I think I am forced to conclude) is that SOMETIMES, for reasons that I haven't been able to nail down, I get a bogus json response. It's intermittent and not very repeatable for any given file, but its very repeatable at some point in a list as I walk through a long list of files. The other script (one being derived from the other, and very similar) accesses metadata for a shorter list of files (only the WG docs, or only the individual submissions, and only if it has been updated since November), so the issue might even be the length of the list of files for all I know.

If you have a clue as to how I might debug this or what information might be helpful to you or Glen, please advise.

> On Mar 16, 2016, at 10:49 AM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Fred,
>

---

From: Glen <[email-masked]>
Date: Wed, 16 Mar 2016 11:56:08 -0700

Hi Fred -

In this case, I would just me the middle-man, reporting this onward to
Henrik, Robert and the Tools Team.  So you did the right thing by
including them, and you don't need to compile a separate report for
me.  :-)  I'm sure Henrik, Robert or others may have questions, so
I've included Robert (and removed IETF-ACTION) here.  :-)

Would everyone use this address group for replies please?

Thanks so much!

Glen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 16 Mar 2016 20:57:32 +0000

On Mar 16, 2016, at 12:18 PM, Henrik Levkowetz <[email-masked]> wrote:
> I have no immediate idea about why you'd get bad JSON occasionally.  If
> it would be possible for you to catch the bad JSON when this happens, it
> might (or might not, of course) provide additional clues.  I'd love to
> see a sample if you can provide one.

OK. I changed the code to use the try/catch logic. FYI, the code has previously walked our local mirror of the internet draft directory to find the subset of drafts that have author emails @cisco.com or that we recognize, and which are current Cisco employees. We will now get the metadata for each such file.

I also stuck in an array named @iwonder, as "I wonder" what the second line of a file response might be. The JSON file comes in as a single line with no \n.

sub get_drafts {
    my $base;
    my @words;
    my @iwonder;
    my $curl = "curl 'https://datatracker.ietf.org/api/v1/doc/document/\?format=json\&name=%s\&limit=0' 2> /dev/null";

    foreach my $name ( keys %drafts ) {

# get objects (including but not limited to internet drafts) that expire after today.

        @iwonder = ();
        open OBJECTS, '-|', sprintf( $curl, $name )
          or die "can't access $name metadata";
        my $json = <OBJECTS>;
        @iwonder = readline OBJECTS unless (eof OBJECTS);
        close OBJECTS;

        if ( defined $json ) {
            my $decoded;

            try {
                $decoded = decode_json($json);
            }
            catch {
                printf STDERR "accessing %s\n", sprintf( $curl, $name );
                warn "caught error: $_ JSON was %json";
                $stop++;
            };

            if ( defined $decoded->{'objects'} ) {

I now ran the program in debug mode stopping in the "catch" clause, and got the following. It looks like I asked for JSON metadata, and instead got a "404 not found" in some odd format. Which is interesting as the file was in the mirror image as of a few hours ago...

	%json
	<!DOCTYPE html>
		...

accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name=draft-dseomn-trans-browsers&limit=0' 2> /dev/null
caught error: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at /users/fred/WWW/json/json-cisco-work.pl line 262
 JSON was %json at /users/fred/WWW/json/json-cisco-work.pl line 266.
 at /users/fred/WWW/json/json-cisco-work.pl line 266
	main::__ANON__[/users/fred/WWW/json/json-cisco-work.pl:268]('JSON text must be an object or array (but found number, strin...') called at /usr/cisco/packages/perl/perl-5.8.8/lib/site_perl/5.8.8/Try/Tiny.pm line 100
	Try::Tiny::try('CODE(0x960ae48)', 'Try::Tiny::Catch=REF(0x960513c)') called at /users/fred/WWW/json/json-cisco-work.pl line 268
	main::get_drafts() called at /users/fred/WWW/json/json-cisco-work.pl line 63
main::CODE(0x960531c)(/users/fred/WWW/json/json-cisco-work.pl:267):
267:			$stop++;
  DB<3> x @iwonder
0  '<!DOCTYPE html>
'
1  '
'
2  '
'
3  '
'
4  '<html lang="en">
'
5  '  <head>
'
6  '    <meta charset="utf-8">
'
7  '    <meta http-equiv="X-UA-Compatible" content="IE=edge">
'
8  '    <title>404 Not Found</title>
'
9  '    <meta name="viewport" content="width=device-width, initial-scale=1">
'
10  '
'
11  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptmono/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>
'
12  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptsans/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>
'
13  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptserif/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>
'
14  '
'
15  '
'

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Mar 2016 00:01:59 +0100

Hi Fred,

On 2016-03-16 21:57, Fred Baker (fred) wrote:
> OK. I changed the code to use the try/catch logic. FYI, the code has
> previously walked our local mirror of the internet draft directory to
> find the subset of drafts that have author emails @cisco.com or that
> we recognize, and which are current Cisco employees. We will now get
> the metadata for each such file.

Right.

> I also stuck in an array named @iwonder, as "I wonder" what the
> second line of a file response might be. The JSON file comes in as a
> single line with no \n.

<<snip code>>
 
> 	   <title>404 Not Found</title>

Oho!

From the more detailed html (which I snipped out) I see that this is indeed
a 404 page from the datatracker.

I've now tweaked the 404 page so that it will (for the time being) give
back the URL and query string it thought it was responding to.  Asking for
the url https://datatracker.ietf.org/foo?bar=baz will give back a page
with this at the beginning:

<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>404 Not Found: /foo?bar=baz </title>

That, together with your debug mode code, should help figure out what the
datatracker _thinks_ it was asked for, and possibly let us pull some more
at the thread.

Best regards,

	Henrik

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 17 Mar 2016 01:50:55 +0000

<title>404 Not Found: /error/HTTP_FORBIDDEN.html.var </title>'

accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name=draft-ietf-anima-bootstrapping-keyinfra&limit=0' 2> /dev/null
caught error: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at /users/fred/WWW/json/json-cisco-work.pl line 290
 at /users/fred/WWW/json/json-cisco-work.pl line 294
	main::__ANON__[/users/fred/WWW/json/json-cisco-work.pl:301]('JSON text must be an object or array (but found number, strin...') called at /usr/cisco/packages/perl/perl-5.8.8/lib/site_perl/5.8.8/Try/Tiny.pm line 100
	Try::Tiny::try('CODE(0xa6baa70)', 'Try::Tiny::Catch=REF(0xa6c0ff4)') called at /users/fred/WWW/json/json-cisco-work.pl line 301
	main::get_drafts() called at /users/fred/WWW/json/json-cisco-work.pl line 63
main::CODE(0xa6c0fa0)(/users/fred/WWW/json/json-cisco-work.pl:299):
299:	                die "";
  DB<5> x $json
0  ''
  DB<6> x @iwonder
0  '<!DOCTYPE html> '
1  ''
2  ''
3  ''
4  '<html lang="en">'
5  '  <head>'
6  '    <meta charset="utf-8">'
7  '    <meta http-equiv="X-UA-Compatible" content="IE=edge">'
8  '    <title>404 Not Found: /error/HTTP_FORBIDDEN.html.var </title>'
9  '    <meta name="viewport" content="width=device-width, initial-scale=1">'
10  ''
11  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptmono/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>'
12  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptsans/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>'
13  '    <link href="https://www.ietf.org/lib/dt/6.17.0/ptserif/stylesheet.css" rel=\'stylesheet\' type=\'text/css\'>'
14  '    '
15  ''
16  '    <link rel="stylesheet" href="https://www.ietf.org/lib/dt/6.17.0/font-awesome/css/font-awesome.min.css">'
17  '    <link rel="stylesheet" href="https://www.ietf.org/lib/dt/6.17.0/ietf/bootstrap/css/bootstrap.min.css">'
18  '    <link rel="stylesheet" href="https://www.ietf.org/lib/dt/6.17.0/ietf/bootstrap/css/bootstrap-theme.min.css">'
19  '    <link rel="stylesheet" href="https://www.ietf.org/lib/dt/6.17.0/ietf/css/ietf.css">'
20  '    <style>'

> On Mar 16, 2016, at 4:01 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Fred,
> 
> --
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
> Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
> send email to [email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Mar 2016 10:48:10 +0100

Hi Fred,

> <title>404 Not Found: /error/HTTP_FORBIDDEN.html.var </title>'

Hmm.

At first I thought "That's really interesting"; but I believe that it's
probably the end result of a chain of redirects; that URL is something
that Apache redirects to, rather than the datatracker.

I think I've managed to identify /api/ calls from your script in the logs
now, and if what's above is the end of the 404 page generation, the logs
seem to show the initial /api/v1/... 404s -- I see 9 of them from March
16th, and each of them that I've tried, have returned 200s on the re-try.

This looks like a bug in the API framework; I'll try to pull on that thread.

	Henrik

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 17 Mar 2016 16:29:29 +0000

> On Mar 17, 2016, at 2:48 AM, Henrik Levkowetz <[email-masked]> wrote:
> 

Thanks

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Mar 2016 13:54:21 +0100

Hi Fred,

>> This looks like a bug in the API framework; I'll try to pull on that thread.

I made a change in the apache/mod_wsgi config yesterday, 2016-03-17 10:16 PST,
which I believe should address the 404 problem.  I haven't seen a single api
query 404 since then; does that agree with what you're seeing?

Best regards,

	Henrik

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 18 Mar 2016 15:55:49 +0000

> On Mar 18, 2016, at 5:54 AM, Henrik Levkowetz <[email-masked]> wrote:
> 

Well... would you believe '<title>403 Forbidden</title>'? Fri Mar 18 08:51:21 PDT 2016

Notice that I got failures on two different drafts, but both accesses were obtaining the metadata for a draft.

104:fred@irp-lnx1% nice perl -w /users/fred/WWW/json/json-cisco-work.pl --wg --individual /users/fred/draft/.current > /users/fred/WWW/json/cisco-drafts.txt

accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name=draft-hares-i2rs-pkt-eca-data-model&limit=0' 2> /dev/null
caught error: malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at /users/fred/WWW/json/json-cisco-work.pl line 290
Died at /users/fred/WWW/json/json-cisco-work.pl line 299.

105:fred@irp-lnx1% date
Fri Mar 18 08:47:07 PDT 2016

106:fred@irp-lnx1% perl -w -d /users/fred/WWW/json/json-cisco-work.pl --wg --individual /users/fred/draft/.current > /users/fred/WWW/json/cisco-drafts.txt

Loading DB routines from perl5db.pl version 1.28
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(/users/fred/WWW/json/json-cisco-work.pl:12):
12:	$rfc_published = '';
  DB<1> v 299
296:	                    chomp $line;
297:	                    printf "%s\n", $line;
298 	                }
299:	                die "";
300:	                $stop++;
301:	            };
302
303:	            if ( defined $decoded->{'objects'} ) {
304:	                my @objects = @{ $decoded->{'objects'} };
305 	              draft_object:
  DB<2> b 299
  DB<3> c
accessing curl 'https://datatracker.ietf.org/api/v1/doc/document/?format=json&name=draft-ram-bfcpbis-sdp-ws-uri&limit=0' 2> /dev/null
caught error: malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at /users/fred/WWW/json/json-cisco-work.pl line 290
 at /users/fred/WWW/json/json-cisco-work.pl line 294
	main::__ANON__[/users/fred/WWW/json/json-cisco-work.pl:301]('malformed JSON string, neither array, object, number, string ...') called at /usr/cisco/packages/perl/perl-5.8.8/lib/site_perl/5.8.8/Try/Tiny.pm line 100
	Try::Tiny::try('CODE(0x9725b70)', 'Try::Tiny::Catch=REF(0x972b084)') called at /users/fred/WWW/json/json-cisco-work.pl line 301
	main::get_drafts() called at /users/fred/WWW/json/json-cisco-work.pl line 63
main::CODE(0x9725f3c)(/users/fred/WWW/json/json-cisco-work.pl:299):
299:	                die "";
  DB<3> p $json
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
  DB<4> x @iwonder
0  '<html><head>'
1  '<title>403 Forbidden</title>'
2  '</head><body>'
3  '<h1>Forbidden</h1>'
4  '<p>You don\'t have permission to access /api/v1/doc/document/'
5  'on this server.<br />'
6  '</p>'
7  '<p>Additionally, a 403 Forbidden'
8  'error was encountered while trying to use an ErrorDocument to handle the request.</p>'
9  '</body></html>'
  DB<5>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Mar 2016 17:15:39 +0100

> Well... would you believe '<title>403 Forbidden</title>'? Fri Mar 18 08:51:21 PDT 2016

Heh!  Yes, I find 3 of them in today's log.

> Notice that I got failures on two different drafts, but both accesses were obtaining the metadata for a draft.

<<snip details>>

Right.  At the moment I have a whisper of a theory about these, and if that's
right, all of these will occur during a very short period of time, so an
immediate re-try on failure should work.  However, my somewhat tenuous theory
also indicates that you should see these less often than you do, so it may be
wrong.  I'll keep poking.

	Henrik

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 19 Mar 2016 00:23:20 -0400

> On Mar 18, 2016, at 12:15 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Signed PGP part
> 

Not sure if another data point helps but I’m getting 403 errors in the IETF app:

2016-03-19 00:19:01.411 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type=area&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:02.594 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type__in=ietf,irtf,iab&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:03.345 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type=wg&state__in=active,proposed,bof,conclude,bof-conc&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:05.352 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&offset=100&limit=100&time__gt=1970-01-01T22%3A00%3A00&type=wg
2016-03-19 00:19:07.643 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=200
2016-03-19 00:19:10.854 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=300
2016-03-19 00:19:14.539 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=400
2016-03-19 00:19:16.337 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=500
2016-03-19 00:19:18.313 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=600
2016-03-19 00:19:23.485 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=700
2016-03-19 00:19:26.113 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=800
2016-03-19 00:19:27.941 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?state__in=active%2Cproposed%2Cbof%2Cconclude%2Cbof-conc&type=wg&limit=100&time__gt=1970-01-01T22%3A00%3A00&offset=900
2016-03-19 00:19:29.176 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:29.440 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type=ag&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:29.888 ietfers[9849:1578125] https://datatracker.ietf.org/api/v1/group/group/?type=rg&time__gt=1970-01-01T22:00:00&limit=100
2016-03-19 00:19:29.995 ietfers[9849:1578125] getJsonUrl Error: Error Domain=com.alamofire.error.serialization.response Code=-1011 "Request failed: forbidden (403)" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x7a97e0f0> { URL: https://datatracker.ietf.org/api/v1/group/group/?type=rg&time__gt=1970-01-01T22:00:00&limit=100 } { status code: 403, headers {
    Connection = "Keep-Alive";
    "Content-Length" = 347;
    "Content-Type" = "text/html; charset=iso-8859-1";
    Date = "Sat, 19 Mar 2016 04:19:29 GMT";
    "Keep-Alive" = "timeout=15, max=86";
    Server = Apache;
} }, NSErrorFailingURLKey=https://datatracker.ietf.org/api/v1/group/group/?type=rg&time__gt=1970-01-01T22:00:00&limit=100, NSLocalizedDescription=Request failed: forbidden (403), com.alamofire.serialization.response.error.data=<3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f4945 54462f2f 44544420 48544d4c 20322e30 2f2f454e 223e0a3c 68746d6c 3e3c6865 61643e0a 3c746974 6c653e34 30332046 6f726269 6464656e 3c2f7469 746c653e 0a3c2f68 6561643e 3c626f64 793e0a3c 68313e46 6f726269 6464656e 3c2f6831 3e0a3c70 3e596f75 20646f6e 27742068 61766520 7065726d 69737369 6f6e2074 6f206163 63657373 202f6170 692f7631 2f67726f 75702f67 726f7570 2f0a6f6e 20746869 73207365 72766572 2e3c6272 202f3e0a 3c2f703e 0a3c703e 41646469 74696f6e 616c6c79 2c206120 34303320 466f7262 69646465 6e0a6572 726f7220 77617320 656e636f 756e7465 72656420 7768696c 65207472 79696e67 20746f20 75736520 616e2045 72726f72 446f6375 6d656e74 20746f20 68616e64 6c652074 68652072 65717565 73742e3c 2f703e0a 3c2f626f 64793e3c 2f68746d 6c3e0a>, NSUnderlyingError=0x79e49750 {Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable content-type: text/html" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x7a97e0f0> { URL: https://datatracker.ietf.org/api/v1/group/group/?type=rg&time__gt=1970-01-01T22:00:00&limit=100 } { status code: 403, headers {
    Connection = "Keep-Alive";
    "Content-Length" = 347;
    "Content-Type" = "text/html; charset=iso-8859-1";
    Date = "Sat, 19 Mar 2016 04:19:29 GMT";
    "Keep-Alive" = "timeout=15, max=86";
    Server = Apache;
} }, NSErrorFailingURLKey=https://datatracker.ietf.org/api/v1/group/group/?type=rg&time__gt=1970-01-01T22:00:00&limit=100, NSLocalizedDescription=Request failed: unacceptable content-type: text/html, com.alamofire.serialization.response.error.data=<3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f4945 54462f2f 44544420 48544d4c 20322e30 2f2f454e 223e0a3c 68746d6c 3e3c6865 61643e0a 3c746974 6c653e34 30332046 6f726269 6464656e 3c2f7469 746c653e 0a3c2f68 6561643e 3c626f64 793e0a3c 68313e46 6f726269 6464656e 3c2f6831 3e0a3c70 3e596f75 20646f6e 27742068 61766520 7065726d 69737369 6f6e2074 6f206163 63657373 202f6170 692f7631 2f67726f 75702f67 726f7570 2f0a6f6e 20746869 73207365 72766572 2e3c6272 202f3e0a 3c2f703e 0a3c703e 41646469 74696f6e 616c6c79 2c206120 34303320 466f7262 69646465 6e0a6572 726f7220 77617320 656e636f 756e7465 72656420 7768696c 65207472 79696e67 20746f20 75736520 616e2045 72726f72 446f6375 6d656e74 20746f20 68616e64 6c652074 68652072 65717565 73742e3c 2f703e0a 3c2f626f 64793e3c 2f68746d 6c3e0a>}}}

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 19 Mar 2016 22:22:51 -0400

Also, this seems like it shouldn’t happen. I’m requesting content type application/json and getting back text/html.

Tom

2016-03-19 22:20:17.798 ietfers[12340:2154099] https://datatracker.ietf.org/api/v1/group/group/?type=area&time__gt=2015-06-12T08:30:50&limit=100
2016-03-19 22:20:18.259 ietfers[12340:2154099] https://datatracker.ietf.org/api/v1/group/group/?type__in=ietf,irtf,iab&time__gt=2014-07-03T10:43:14&limit=100
2016-03-19 22:20:18.414 ietfers[12340:2154099] https://datatracker.ietf.org/api/v1/group/group/?type=wg&state__in=active,proposed,bof,conclude,bof-conc&time__gt=2016-03-15T10:16:22&limit=100
2016-03-19 22:20:18.565 ietfers[12340:2154099] https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100
2016-03-19 22:20:18.657 ietfers[12340:2154099] getJsonUrl Error: Error Domain=com.alamofire.error.serialization.response Code=-1011 "Request failed: forbidden (403)" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x79631110> { URL: https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100 } { status code: 403, headers {
    Connection = "Keep-Alive";
    "Content-Length" = 347;
    "Content-Type" = "text/html; charset=iso-8859-1";
    Date = "Sun, 20 Mar 2016 02:20:18 GMT";
    "Keep-Alive" = "timeout=15, max=97";
    Server = Apache;
} }, NSErrorFailingURLKey=https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100, NSLocalizedDescription=Request failed: forbidden (403), com.alamofire.serialization.response.error.data=<3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f4945 54462f2f 44544420 48544d4c 20322e30 2f2f454e 223e0a3c 68746d6c 3e3c6865 61643e0a 3c746974 6c653e34 30332046 6f726269 6464656e 3c2f7469 746c653e 0a3c2f68 6561643e 3c626f64 793e0a3c 68313e46 6f726269 6464656e 3c2f6831 3e0a3c70 3e596f75 20646f6e 27742068 61766520 7065726d 69737369 6f6e2074 6f206163 63657373 202f6170 692f7631 2f67726f 75702f67 726f7570 2f0a6f6e 20746869 73207365 72766572 2e3c6272 202f3e0a 3c2f703e 0a3c703e 41646469 74696f6e 616c6c79 2c206120 34303320 466f7262 69646465 6e0a6572 726f7220 77617320 656e636f 756e7465 72656420 7768696c 65207472 79696e67 20746f20 75736520 616e2045 72726f72 446f6375 6d656e74 20746f20 68616e64 6c652074 68652072 65717565 73742e3c 2f703e0a 3c2f626f 64793e3c 2f68746d 6c3e0a>, NSUnderlyingError=0x7986f8d0 {Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable content-type: text/html" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x79631110> { URL: https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100 } { status code: 403, headers {
    Connection = "Keep-Alive";
    "Content-Length" = 347;
    "Content-Type" = "text/html; charset=iso-8859-1";
    Date = "Sun, 20 Mar 2016 02:20:18 GMT";
    "Keep-Alive" = "timeout=15, max=97";
    Server = Apache;
} }, NSErrorFailingURLKey=https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100, NSLocalizedDescription=Request failed: unacceptable content-type: text/html, com.alamofire.serialization.response.error.data=<3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f4945 54462f2f 44544420 48544d4c 20322e30 2f2f454e 223e0a3c 68746d6c 3e3c6865 61643e0a 3c746974 6c653e34 30332046 6f726269 6464656e 3c2f7469 746c653e 0a3c2f68 6561643e 3c626f64 793e0a3c 68313e46 6f726269 6464656e 3c2f6831 3e0a3c70 3e596f75 20646f6e 27742068 61766520 7065726d 69737369 6f6e2074 6f206163 63657373 202f6170 692f7631 2f67726f 75702f67 726f7570 2f0a6f6e 20746869 73207365 72766572 2e3c6272 202f3e0a 3c2f703e 0a3c703e 41646469 74696f6e 616c6c79 2c206120 34303320 466f7262 69646465 6e0a6572 726f7220 77617320 656e636f 756e7465 72656420 7768696c 65207472 79696e67 20746f20 75736520 616e2045 72726f72 446f6375 6d656e74 20746f20 68616e64 6c652074 68652072 65717565 73742e3c 2f703e0a 3c2f626f 64793e3c 2f68746d 6c3e0a>}}}

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 19 Mar 2016 22:45:28 -0400

And another problem:

I tried to download 200 sessions and they all have the same group (“TLS). You can see the log here:

https://gist.github.com/pusateri/0645197115770266efcb

Can I suggest we go back to the old API code until after this IETF. I need to submit the IETFers app for approval in the next day or two and I can’t submit it with the API not working.

Thanks,
Tom

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 20 Mar 2016 05:05:59 +0100

Hi Tom,

As it says in the list footer:
Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb

I've taken the debug conversation with Fred off-list; the issue below is
separate and would better be captured in the issue tracker.

	Henrik

On 2016-03-20 03:22, Tom Pusateri wrote:
> } }, NSErrorFailingURLKey=https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100, NSLocalizedDescription=Request failed: forbidden (403), com.alamofire.serialization.response.error.data=<3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f4945 54462f2f 44544420 48544d4c 20322e30 2f2f454e 223e0a3c 68746d6c 3e3c6865 61643e0a 3c746974 6c653e34 30332046 6f726269 6464656e 3c2f7469 746c653e 0a3c2f68 6561643e 3c626f64 793e0a3c 68313e46 6f726269 6464656e 3c2f6831 3e0a3c70 3e596f75 20646f6e 27742068 61766520 7065726d 69737369 6f6e2074 6f206163 63657373 202f6170 692f7631 2f67726f 75702f67 726f7570 2f0a6f6e 20746869 73207365 72766572 2e3c6272 202f3e0a 3c2f703e 0a3c703e 41646469 74696f6e 616c6c79 2c206120 34303320 466f7262 69646465 6e0a6572 726f7220 77617320 656e636f 756e7465 72656420 7768696c 65207472 79696e67 20746f20 75736520 616e2045 72726f72 446f6375 6d656e74 20746f20 68616e64 6c652074 68652072 65717565 73742e3c 2f703e0a 3c2f626f 64793e3c 2f
68746d 6c3e0a>, NSUnderlyingError=0x7986f8d0 {Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable content-type: text/html" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x79631110> { URL: https://datatracker.ietf.org/api/v1/group/group/?type=team&time__gt=2015-10-31T20:06:04&limit=100 } { status code: 403, headers {

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 20 Mar 2016 05:13:29 +0100

Hi Tom,

Inline:

> Can I suggest we go back to the old API code until after this IETF. I need to submit the IETFers app for approval in the next day or two and I can’t submit it with the API not working.

The issue with 404s and 403s returned from API calls has appeared with
the upgrade of the server OS, which has pulled in a different Apache
version, a different MySQL version, and other things.  I'm afraid there's
no way to revert to the old OS and application versions.

The issue above seems completely unrelated to that, and looks more like
missing query arguments.  I'll look into it more with you if you'll follow
the advice in the list footer, and report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb .

	Henrik