Shavar supports the gethash directive, but it doesn't seem to be working. STR: 1) Delete "mozpub-track-digest256" from pref urlclassifier.disallowcompletions. 2) Visit http://people.mozilla.org/~fmarier/test_tp.html Expected results: Resources gets blocked, just like if 1) hadn't been done. Actual results: Nothing gets blocked.

Francois, can you turn on all the relevant debugging and find exactly how the request is failing? browser.safebrowsing.debug might be useful too in addition to the usual NSPR modules.

That's because we aren't getting a response (NS_ERROR_NOT_AVAILABLE) from the endpoint. NB: I changed from https to http in the attached screenshot in case I needed to wireshark, but everything else is as out of the box. Ryan, can you take a look and see if anything obvious is wrong? This is the endpoint: https://tracking.services.mozilla.com/gethash?client=SAFEBROWSING_ID&appver=39.0a1&pver=2.2

[ Also being tracked here: https://github.com/mozilla-services/shavar/issues/32 ] From the production logs: ParseError('Improbably small or large gethash header size: 3',) That means that the header portion of the POST body is only 3 characters long(most probably the string "4:4" or "4:8"). From our discussions last year, the minimum size of a call to gethash would be four hash prefixes: the prefix for the actual URL that's being looked up and three other randomly generated prefixes(essentially 3 * 4-random-bytes). The error from the logs indicates that one or fewer random prefixes are being included in the request. Do we need to revisit what the safe minimum gethash POST body should be? Definitely at least one service side bug: at least a 500 response should have been included but probably a 400 to meet the protocol spec.

On the (In reply to Ryan Tilder [:rtilder] from comment #3) > [ Also being tracked here: > https://github.com/mozilla-services/shavar/issues/32 ] > > > From the production logs: ParseError('Improbably small or large gethash > header size: 3',) > > That means that the header portion of the POST body is only 3 characters > long(most probably the string "4:4" or "4:8"). > > From our discussions last year, the minimum size of a call to gethash would > be four hash prefixes: the prefix for the actual URL that's being looked up > and three other randomly generated prefixes(essentially 3 * 4-random-bytes). > The error from the logs indicates that one or fewer random prefixes are > being included in the request. Do we need to revisit what the safe minimum > gethash POST body should be? On the server side, the answer should be 1. It should be up to the client to determine how many gethash requests to send in a single request.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.