FS#18626 - aur rpc honks on unicode input

Attached to Project: AUR web interface
Opened by eliott (cactus) - Wednesday, 10 March 2010, 05:43 GMT
Last edited by Lukas Fleischer (lfleischer) - Monday, 21 February 2011, 09:51 GMT
Task Type Bug Report
Category Backend
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version 1.6.0
Due in Version 1.8.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The rpc interface appears to honk on unicode input.

http://aur.archlinux.org/rpc.php?type=search&arg=ñ

Result: http 500 error (puked!)

Also of note. The main site aur search code seems to just turn "ñ" into "n" (note the lack of the tilde).

Not sure what path the devs want to take with fixing the aur.rpc. Whether it be to perform the same metamorphisis upon the search terms as the main site, or to fix them both in a different way. Whichever direction is chosen, it would make sense to me that they at least be consistent with each other.
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Monday, 21 February 2011, 09:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 1.8.0.
Comment by eliott (cactus) - Wednesday, 10 March 2010, 05:45 GMT
Additional lulz are had by the above 500 error actually showing an http response code of 200 OK.

curl -I "http://aur.archlinux.org/rpc.php?type=search&arg=ñ"
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache, must-revalidate
Expires: Tue, 11 Oct 1988 22:00:00 GMT
Pragma: no-cache
Date: Wed, 10 Mar 2010 05:44:00 GMT
Server: lighttpd/1.4.26

curl "http://aur.archlinux.org/rpc.php?type=search&arg=ñ"
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>500 - Internal Server Error</title>
</head>
<body>
<h1>500 - Internal Server Error</h1>
</body>
</html>
Comment by Loui Chang (louipc) - Saturday, 13 March 2010, 05:14 GMT
I'm not 100% sure, but you may be misinterpreting the meaning of -I there.
-I fetches -only- the header for that file, so the server probably isn't even passing the parameters.

-D will dump the header and it does end up being a server error.
wget -S results in the same.

Thanks for the report.
Comment by eliott (cactus) - Saturday, 13 March 2010, 06:22 GMT
actually, I realize that -I only does a HEAD request.

From rfc2616:
"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification."

Interesting. There may be some interplay with apache and php going on...dunno.

So anyway.. When I use -i (which dumps the header on a get as well as the body), I do see the 500 level error.
So disregard that part of the report.
:)
Comment by Lukas Fleischer (lfleischer) - Tuesday, 25 January 2011, 10:16 GMT
Works locally for me. This must be some web server configuration fail. I'll look into that.
Comment by Lukas Fleischer (lfleischer) - Wednesday, 02 February 2011, 15:53 GMT
  • Field changed: Due in Version (Undecided → 1.8.0)
Fixed in the master branch [1].

[1] http://projects.archlinux.org/aur.git/commit/?id=da2ebb667b7a332ddd8d905bf9b9a8694765fed6

Loading...