Adding entry through the api returns "500 Internal Server Error"

[timokau]

Issue details

I'm trying to write a simple shell script to add an entry to my wallabag account. I've got the authorization working properly, and getting all entries works without problems.
Adding an entry however returns an "Internal Server Error".
If I'm reading the api documentation correctly I provide the server with all the information it needs.
Here's the script:

#!/bin/sh

CLIENT_ID='<client_id>'
CLIENT_SECRET='<client_secret>'
USERNAME='<username>'
PASSWORD='<password>'

WALLABAG_URL='http://v2.wallabag.org'

access_token=$(http POST "$WALLABAG_URL/oauth/v2/token" \
    grant_type=password \
    client_id="$CLIENT_ID" \
    client_secret="$CLIENT_SECRET" \
    username="$USERNAME" \
    password="$PASSWORD" | grep 'access_token' | awk -F'"' '{print $4}')

# This works
# http GET "$WALLABAG_URL/api/entries.json" \
#     Authorization:"Bearer $access_token"

# This doesn't
http POST "$WALLABAG_URL/api/entries.json" \
    Authorization:"Bearer $access_token" \
    url:'http://www.text.com/article.html' \
    tags:'' \
    starred:'false' \
    archive:'false'

And here's the output:

{"error":{"code":500,"message":"Internal Server Error"}}

Environment

I'm using the hosted beta (beta 2).

Steps to reproduce/test case

See the script above.

[tcitworld]

Can't see why for now, but wallabag doesn't retrieves the URL, which is NULL. Working on it.

EDIT : Nothing is passed to $request

[tcitworld]

OK, so it seems it doesn't work with HTTPie. For some reason the url parameter seems badly encoded and may be sent as \"url\" instead. But it works with curl for instance instead. If any one got an idea...

curl -H "Authorization: Bearer $access_token" --data "url=http://www.text.com/article.html&tags=atag" $WALLABAG_URL/api/entries.json

[timokau]

I can confirm that it works with curl. Weired. Anyway, thanks for taking a look at it.

[nicosomb]

Can we close?

[timokau]

For my purposes, the problem is solved. The original issue still exists though. I don't know if the problem lies with wallabag or httpie. If its a problem with wallabag, maybe the issue shouldn't be closed yet.

[tcitworld]

Maybe we can ask for help on HTTPie's side (cc @jkbrzt) ?

[jkbrzt]

The HTTPie command seems wrong because : is used for headers, so the data is being sent as such: starred:'false' adds a header named starred with the value of false.

For data, one needs to use the = sign: starred='false'

And looking at the curl example it looks like the request should be form-encoded, so the HTTPie command in its simplest form should probably look like this:

http --form "$WALLABAG_URL/api/entries.json" \
    Authorization:"Bearer $access_token" \
    url=http://www.text.com/article.html \
    tags= \
    starred=false \
    archive=false

I recommend using the --verbose option when crafting non-trivial request to see exactly what the request that is being sent looks like.

[tcitworld]

Thank you for taking the time to answer. We should have seen this, sorry.

[jkbrzt]

@tcitworld no worries, happy to help

[timokau]

Thank you for your help, this does successfully add the entry.
But, using the command @jkbrzt recommended:

http --verbose --form "$WALLABAG_URL/api/entries.json" \
    Authorization:"Bearer $access_token" \
    starred="false" \
    url="http://www.test.com/article.html" \
    archive="false"

"starred" and "archive" are set to true by the server (even though the data is sent correctly).
Here's the request being sent:

POST /api/entries.json HTTP/1.1
Host: v2.wallabag.org
Accept-Encoding: gzip, deflate
Authorization: Bearer <...>
Accept: */*
Connection: keep-alive
User-Agent: HTTPie/0.9.3
Content-Length: 72
Content-Type: application/x-www-form-urlencoded; charset=utf-8

url=http%3A%2F%2Fwww.test.com%2Farticle.html&starred=false&archive=false

And the server's response:

HTTP/1.1 200 OK
Date: Tue, 15 Mar 2016 09:48:13 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=<...>; expires=Wed, 15-Mar-17 09:48:12 GMT; path=/; domain=.wallabag.org; HttpOnly
0: application/json
Cache-Control: no-cache
Server: cloudflare-nginx
CF-RAY: 283f0c6419d50725-AMS
Content-Encoding: gzip

{
"id":412,
"title":"No title found",
"url":"https:\/\/www.test.com\/",
"is_archived":true,
"is_starred":true,
"content":"wallabag can't retrieve contents for this article. Please report this issue to us.",
"created_at":"2016-03-15T10:48:13+0100",
"updated_at":"2016-03-15T10:48:13+0100",
"mimetype":"text\/html",
"reading_time":0,
"domain_name":"www.test.com",
"user":{<...>},
"tags":[],
"_links":
{
"self":{"href":"\/api\/entries\/412"}
}
}

Entirely removing "archive" and "starred" from the request uses the correct defaults (false).

[tcitworld]

"starred" and "archive" are set to true by the server (even though the data is sent correctly).

I can't test right now, but can you try removing the quotes surrounding "false" ?

[timokau]

Tried it, that makes no difference.

[tcitworld]

Got it. Fix on it's way. You can put 0 instead of false for now.

[timokau]

Awesome, thanks

[tcitworld]

OK, so we're going with 0/1 instead of true/false for these parameters.