I'm not sure yet what that buys me, other than being potentially interesting that it doesn't report an error. I don't understand why the ProxyClientFactory is starting and stopping yet.
mbarnett helped me use the second one as verification that the database tables are up to date on staging: the following query did return the appropriate value on staging, identical to production.
SELECT LibraryFileAlias.content, LibraryFileAlias.date_created, LibraryFileAlias.expires, LibraryFileAlias.filename, LibraryFileAlias.hits, LibraryFileAlias.id, LibraryFileAlias.last_accessed, LibraryFileAlias.mimetype, LibraryFileAlias.restricted FROM LibraryFileAlias, LibraryFileContent WHERE LibraryFileAlias.content = LibraryFileContent.id AND LibraryFileAlias.id = 42395443 AND LibraryFileAlias.restricted = True
That query mirrors the search done in lib/canonical/librarian/db.py, in Library.getAlias, after the token code that should not be pertinent in this case.
alias = LibraryFileAlias.selectOne(AND( LibraryFileAlias.q.id==aliasid, LibraryFileAlias.q.contentID==LibraryFileContent.q.id, LibraryFileAlias.q.restricted==restricted,
))
if alias is None:
raise LookupError("No file alias with LibraryFileContent")
return alias
So, that LookupError shouldn't be the one triggering a 404.
The only other reasonable possibility for a 404 seem to be if the hostname does not match up (see canonical/librarian/web.py in LibraryFileAliasResource .getChild in the block that includes "if '.restricted.' in hostname:"). I think we'll need to add some logging to investigate that, so I'll do that next.
The other possibilities in web.py are if the alias is not an int (it is, 42395443) or if the dbname is not the same as what came in the request (it is, tdGJABsFQRvCCFlFQFUZlZSJOd9.txt).
Notes...
Here's an example of the librarian's log for an instance of the first one (https:/ /lp-oops. canonical. com/oops/ ?oopsid= OOPS-1753S156):
2010-10-19 15:37:21+0000 [-] Starting factory <twisted. web.proxy. ProxyClientFact ory instance at 0x61b6fc8> client] 91.189.90.174 - - [19/Oct/ 2010:15: 37:20 +0000] "GET /57500648/ e47a938c- d605-11df- 88ae-001e0bc395 7e.txt HTTP/1.0" 404 146 "-" "Python-urllib/2.6" client] Stopping factory <twisted. web.proxy. ProxyClientFact ory instance at 0x61b6fc8>
2010-10-19 15:37:21+0000 [ProxyClient,
2010-10-19 15:37:21+0000 [ProxyClient,
The second one:
2010-10-19 15:39:46+0000 [-] Starting factory <twisted. web.proxy. ProxyClientFact ory instance at 0x5efc8c0> client] 91.189.90.174 - - [19/Oct/ 2010:15: 39:46 +0000] "GET /42395443/ tdGJABsFQRvCCFl FQFUZlZSJOd9. txt HTTP/1.0" 404 146 "-" "Python-urllib/2.6" client] Stopping factory <twisted. web.proxy. ProxyClientFact ory instance at 0x5efc8c0>
2010-10-19 15:39:47+0000 [ProxyClient,
2010-10-19 15:39:47+0000 [ProxyClient,
I'm not sure yet what that buys me, other than being potentially interesting that it doesn't report an error. I don't understand why the ProxyClientFactory is starting and stopping yet.
mbarnett helped me use the second one as verification that the database tables are up to date on staging: the following query did return the appropriate value on staging, identical to production.
SELECT LibraryFileAlia s.content, LibraryFileAlia s.date_ created, LibraryFileAlia s.expires, LibraryFileAlia s.filename, LibraryFileAlia s.hits, LibraryFileAlia s.id, LibraryFileAlia s.last_ accessed, LibraryFileAlia s.mimetype, LibraryFileAlia s.restricted FROM LibraryFileAlias, LibraryFileContent WHERE LibraryFileAlia s.content = LibraryFileCont ent.id AND LibraryFileAlias.id = 42395443 AND LibraryFileAlia s.restricted = True
https:/ /pastebin. canonical. com/38822/
That query mirrors the search done in lib/canonical/ librarian/ db.py, in Library.getAlias, after the token code that should not be pertinent in this case.
alias = LibraryFileAlia s.selectOne( AND(
LibraryFil eAlias. q.id==aliasid,
LibraryFil eAlias. q.contentID= =LibraryFileCon tent.q. id,
LibraryFil eAlias. q.restricted= =restricted, ent")
))
if alias is None:
raise LookupError("No file alias with LibraryFileCont
return alias
So, that LookupError shouldn't be the one triggering a 404.
The only other reasonable possibility for a 404 seem to be if the hostname does not match up (see canonical/ librarian/ web.py in LibraryFileAlia sResource .getChild in the block that includes "if '.restricted.' in hostname:"). I think we'll need to add some logging to investigate that, so I'll do that next.
The other possibilities in web.py are if the alias is not an int (it is, 42395443) or if the dbname is not the same as what came in the request (it is, tdGJABsFQRvCCFl FQFUZlZSJOd9. txt).
So, I'm hoping it is that hostname thing.