On Nov 5, 3:34 pm, Andrew Leach <andrew.leac...@googlemail.com> wrote:
> You are client-side. What are you doing server-side when the page is
> resubmitted with some parameters? If you don't know what the callback
> argument does, are you using a callback? Do you need it?
On the server side I'm using the lat/long to query our database for
gas stations within a given radius and then I display the sites for
the user on a google map. I'm using a callback to submit the form
with a lat/long rather than an un-geocoded address because it's easier
for me than coming up with another geocoding solution on the server
side.
> Perhaps in this case the blacklisting is not automatically temporary,
> as Barry has hinted.
If that's the case and I'm now permanently blacklisted and can't use
the Maps API behind my proxy, any suggestions? Some possible
solutions I've come up with are: a) ask my networking team to request
new IP addresses for our proxy servers; b) come up with my own
geocoding solution on the server side; c) try to come up with another
way to use the google geocoder without using the Maps API.
I am definitely not working outside of the API. I am using google code
verbatim. Even Google's own example page is failing for me (and
others), which I pointed out in the original post. The JSON request
with the callback field is generated from the google-hosted javascript
file.
It's more than a little frustrating seeing zero responses from any
developers at Google on this issue. My employers were even considering
going with an enterprise solution for the maps API, but I'll be damned
if I'm going to recommend we pay $10k+ for a service that suddenly
stops working one day out of the blue, for no discernible reason.
On Nov 5, 3:51 pm, Barry Hunter <barrybhun...@googlemail.com> wrote:
> My guess is Google have noticed people abusing the geocoder and have
> started to actively block certain requests.
> calls that use callback and dont originate from the Maps API itself
> are a prime candidate for blocking
> (because using callback yourself means you working outside of the API)
> And requests from behind a proxy are subject to extra scrutiny, so a
> few legitimate requests are getting caught in the crossfire?
> > I am also having the exact same problem. The geocoding URLs return
> > 400 but when I remove &callback they work. The requests also work
> > when I plug in outside of my proxy servers.
> > My issue mysteriously started within the past day or so. My mapping
> > pages have been working great for the past 18 months or so (until now,
> > that is).
> > On Nov 4, 11:58 am, Andrew Leach <acle...@btinternet.com> wrote:
> >> On Nov 4, 3:00 pm, Crazydj81 <wim.vang...@gmail.com> wrote:
> >> Given that you're also having difficulty with your own page in this
> >> threadhttp://groups.google.com/group/google-maps-api/browse_thread/thread/6...
> >> and no-one else is, it would appear to be something to do with the way
> >> your network or client is sending the request or interpreting the
> >> response.
> >> You may be able to investigate the response with Firebug, but if all
> >> that is coming back is "invalid request" or something similar, then it
> >> will be the request as received by the server which is suspect. That
> >> may not resemble the request which leaves your browser.
> >> Andrew
> > --
> > You received this message because you are subscribed to the Google Groups "Google Maps API" group.
> > To post to this group, send email to google-maps-api@googlegroups.com.
> > To unsubscribe from this group, send email to google-maps-api+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/google-maps-api?hl=en.
> I am definitely not working outside of the API. I am using google code
> verbatim. Even Google's own example page is failing for me (and
> others), which I pointed out in the original post.
Understood. All the "me too" posts are clouding the issue a bit.
> The JSON request
> with the callback field is generated from the google-hosted javascript
> file.
Yup. It appears Google have stepped up security here, so as to detect
and reject geocoding requests with callback parameters that don't
appear to originate from Google's own API. So as to prevent abusers.
Something in your network is stripping off or replacing referrer
headers or suchlike so that Google can't tell your requests come from
a legitimate API based webpage.
> It's more than a little frustrating seeing zero responses from any
> developers at Google on this issue.
> > I am definitely not working outside of the API. I am using google code
> > verbatim. Even Google's own example page is failing for me (and
> > others), which I pointed out in the original post.
> Understood. All the "me too" posts are clouding the issue a bit.
> > The JSON request
> > with the callback field is generated from the google-hosted javascript
> > file.
> Yup. It appears Google have stepped up security here, so as to detect
> and reject geocoding requests with callback parameters that don't
> appear to originate from Google's own API. So as to prevent abusers.
> Something in your network is stripping off or replacing referrer
> headers or suchlike so that Google can't tell your requests come from
> a legitimate API based webpage.
> > It's more than a little frustrating seeing zero responses from any
> > developers at Google on this issue.
Thanks, I was under the impression this group was read by Google devs
as well. And thanks to Andy for reporting the defect, I hope this get
resolved soon.
On Nov 5, 8:42 pm, Rossko <ros...@culzean.clara.co.uk> wrote:
> Thanks, I was under the impression this group was read by Google devs
> as well. And thanks to Andy for reporting the defect, I hope this get
> resolved soon.
> On Nov 5, 8:42 pm, Rossko <ros...@culzean.clara.co.uk> wrote:
I don't think anyone has actually demonstrated why the callback
parameter is necessary. As far as I can see it shouldn't be needed
server-side because there are other means of getting the data and
processing it (eg XML); and client-side the normal GClientGeocoder of
the API is expected to be used. So Google has tightened up the
security and using an *undocumented* parameter now fails. Using the
HTTP call in a documented fashion doesn't.
Unless I've missed something, nobody has demonstrated why the callback
is necessary and should be documented. I think that this is needed if
the reported Issue(s) are not going to be marked as "WontFix".
ehierhager: I'm not sure that is quite the same. Those folk are using
the geocoder in undocumented ways, and are perhaps being deliberately
blocked. However, something unusual about your particular network
means you are getting caught in the crossfire when using the
documented method e.g. Googles example.
Ah, good catch. I saw the 400 error on requesting http://maps.google.com/maps/geo with the callback parameter and assumed it was the same thing.
Slightly different problem I guess.
On Nov 8, 3:04 pm, Rossko <ros...@culzean.clara.co.uk> wrote:
> ehierhager: I'm not sure that is quite the same. Those folk are using
> the geocoder in undocumented ways, and are perhaps being deliberately
> blocked. However, something unusual about your particular network
> means you are getting caught in the crossfire when using the
> documented method e.g. Googles example.
Correction. Issues 1872 and 1895 are different since they're
attempting to utilize issue geocoding requests via JSONP, which is not
a supported means to do client-side geocoding.
Issue 1902 on the other hand looks, smells and sounds like a quota
limit. I'm currently investigating As Andy pointed out, stars are in
fact important, and we do use them to help gauge which issues are most
impacting.
On Nov 9, 7:35 am, ehierhager <ehierha...@philasd.org> wrote:
> Ah, good catch. I saw the 400 error on requestinghttp://maps.google.com/maps/geo > with the callback parameter and assumed it was the same thing.
> Slightly different problem I guess.
> On Nov 8, 3:04 pm, Rossko <ros...@culzean.clara.co.uk> wrote:
> > ehierhager: I'm not sure that is quite the same. Those folk are using
> > the geocoder in undocumented ways, and are perhaps being deliberately
> > blocked. However, something unusual about your particular network
> > means you are getting caught in the crossfire when using the
> > documented method e.g. Googles example.
>I don't think anyone has actually demonstrated why the callback >parameter is necessary.
My understanding is that GClientGeocoder uses it to match the replies to the requests, thus allowing multiple geocode calls to be in flight at the same time, using the same GClientGeocoder instance. The server sends back the callback parameter, and GClientGeocoder uses it to determine which .getLocations() or .getLatLng() call to call back.
Compare GDirections, which doesn't use a callback parameter. If you make two simultaneous requests with the same GDirections instance, you lose one of them.
2009/11/9 Mike Williams <nos...@econym.demon.co.uk>:
> Wasn't it Andrew Leach who wrote:
>>I don't think anyone has actually demonstrated why the callback
>>parameter is necessary.
> My understanding is that GClientGeocoder uses it to match the replies to
> the requests, thus allowing multiple geocode calls to be in flight at
> the same time, using the same GClientGeocoder instance. The server sends
> back the callback parameter, and GClientGeocoder uses it to determine
> which .getLocations() or .getLatLng() call to call back.
My understanding of Andrews question is why a user is using it in
*user code* - the API can use it behind the scenes. But its not a
documented parameter and a user shouldnt be using it directly (for
example with jquery)
The Maps API provides two interfaces to the Geocoder, GClientGeocoder
in a browser. And a HTTP interface for access from server side code.
Nowhere is it documented that Google offers a direct query interface
for using in a browser. And as such it doesnt fall within the terms of
use.
> Compare GDirections, which doesn't use a callback parameter. If you make
> two simultaneous requests with the same GDirections instance, you lose
> one of them.
> You received this message because you are subscribed to the Google Groups "Google Maps API" group.
> To post to this group, send email to google-maps-api@googlegroups.com.
> To unsubscribe from this group, send email to google-maps-api+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-maps-api?hl=en.
On Nov 9, 7:35 pm, Barry Hunter <barrybhun...@googlemail.com> wrote:
> My understanding of Andrews question is why a user is using it in
> *user code* - the API can use it behind the scenes. But its not a
> documented parameter and a user shouldnt be using it directly (for
> example with jquery)
Yes: that was what I meant. Sorry, should have made the back-reference
to previous postings clearer.
I posted my IPs in issue #1902 (http://code.google.com/p/gmaps-api- issues/issues/detail?id=1902) and haven't received any response yet,
but I guess they unblocked me.
|
