This is a good example of why one must be careful with multiple GREEDYDATA and/or DATA patterns. Your GREEDYDATA in SJTKEYNAME will indeed be greedy and match up until the last colon which for some lines happens to be after "http:".
You should always use as strict boundary conditions as you can. The key in each line doesn't consist of "any number of arbitrary characters" (a reasonable interpretation of GREEDYDATA), it's rather "any number of arbitrary characters except colon". If we translate that back into a grok pattern we get this:
SJTKEYNAME %{NOTSPACE}[^:]*
Well, technically this pattern requires a non-empty key (because of the leading NOTSPACE) but that's probably a good idea anyway.
Secondly, why include %{SPACE} in SJTKEYVALUE? The space isn't really part of the value is it?