80.194.54.42 - - [19/Apr/2003:12:53:47 -0700] "OPTIONS * HTTP/1.0" 200 -
80.194.54.42 - - [19/Apr/2003:12:53:48 -0700] "OPTIONS * HTTP/1.0" 200 -

These trace back to google: about every 25minutes

64.68.86.54 - - [19/Apr/2003:14:36:41 -0700] "\x80%\x01\x03\x01" 501 -
64.68.86.79 - - [19/Apr/2003:14:36:43 -0700] "\x80%\x01\x03\x01" 501 -

hi, if it traces back to google its probably just a robot searching your site, thats very common, though the other numbers are strange, they might be a scan looking for a bug or trying to exploit something,.. though its just generating a 501 error,... posibly nothing to worry about

regards

There is absolutely no reason why google should be sending malformed queries like that ("OPTIONS *" is normal, but "\x80%\x01\x03\x01" really looks like an attempt at a sprintf exploit). If I were you, I'd be contacting abuse@google.com to alert them to this.

Thanks.

I did contact google. I'll post a reply.

There is absolutely no reason why google should be sending malformed queries like that ("OPTIONS *" is normal, but "\x80%\x01\x03\x01" really looks like an attempt at a sprintf exploit). If I were you, I'd be contacting abuse@google.com to alert them to this.

Just what is OPTIONS * It's coming from NL

Originally written in RFC 2068
The OPTIONS method represents a request for information about the
communication options available on the request/response chain
identified by the Request-URI. This method allows the client to
determine the options and/or requirements associated with a resource,
or the capabilities of a server, without implying a resource action
or initiating a resource retrieval.

Unless the server's response is an error, the response MUST NOT
include entity information other than what can be considered as
communication options (e.g., Allow is appropriate, but Content-Type
is not). Responses to this method are not cachable.

If the Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server as a whole. A 200 response SHOULD
include any header fields which indicate optional features
implemented by the server (e.g., Public), including any extensions
not defined by this specification, in addition to any applicable
general or response-header fields. As described in section 5.1.2, an
"OPTIONS *" request can be applied through a proxy by specifying the
destination server in the Request-URI without any path information.

If the Request-URI is not an asterisk, the OPTIONS request applies
only to the options that are available when communicating with that
resource. A 200 response SHOULD include any header fields which
indicate optional features implemented by the server and applicable
to that resource (e.g., Allow), including any extensions not defined
by this specification, in addition to any applicable general or
response-header fields. If the OPTIONS request passes through a
proxy, the proxy MUST edit the response to exclude those options
which apply to a proxy's capabilities and which are known to be
unavailable through that proxy.

Thanks cperciva, but why would someone from the Netherlands want to know "about the communication options available"

How is this sent anyway?

OPTIONS is commonly used by streaming media protocols; with the amount of DNS cruft around, it's quite possible that someone is trying to connect to a server which moved ages ago.

Just ignore it.

Google Search brings up:
http://www.mail-archive.com/modssl-users@modssl.org/msg15426.html

Don't know if that's any help.

Thanks vour.

Not exactly sure what it all means but since these were hitting the box every 25 minutes, I blocked the IP until I hear from google.

Google says it's just a sypder

http://www.google.com/bot.html