Skip Menu |

This queue is for tickets about the HTTP-Message CPAN distribution.

Report information
The Basics
Id: 68644
Status: resolved
Priority: 0/
Queue: HTTP-Message
People
Owner: Nobody in particular
Requestors: LGODDARD [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Sat Jun 04 09:33:39 2011 LGODDARD [...] cpan.org - Ticket created
Subject: HTTP::Request::Common OPTIONS
Would it be possible to add OPTIONS in the near future? If I sent a patch, would you take a look? This would allow all sorts of dependent modules to be more useful to me - LWP::UserAgent, Mechanize, Test::Mechanize. Thank you for all your very helpful modules. Lee
  Sat Jun 04 09:51:12 2011 GAAS [...] cpan.org - Correspondence added
So, you would argue that "OPTIONS" is a commonly used method? Did you expect to pass Content to OPTIONS? If so, in what format? An interesting issue is that there is no way to construct an "OPTIONS *" request with LWP. HTTP::Request needs an absolute URI with the method. So, we would have to make it: OPTIONS http://example.com/* and then turn "/*" into "*". It would then not be any way to ask for the OPTIONS of the "/*" resource.
  Sat Jun 04 09:51:13 2011 The RT System itself - Status changed from 'new' to 'open'
  Sun Jun 05 13:57:57 2011 lee [...] leegoddard.net - Correspondence added
Subject: Re: [rt.cpan.org #68644] HTTP::Request::Common OPTIONS
Date: Sun, 05 Jun 2011 19:57:45 +0200
To: bug-HTTP-Message [...] rt.cpan.org
From: Lee Goddard <leegee [...] gmail.com>
On 04/06/2011 15:51, Gisle_Aas via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68644> > > So, you would argue that "OPTIONS" is a commonly used method?
Well... more common than CONNECT....? I have found myself doing a lot of AJAX programming in the past few years, for which I seem to need to sub-classing a lot of common Perl modules, to a greater or lesser degree. Show quoted text
> Did you expect to pass Content to OPTIONS? If so, in what format?
I have never found a need to, no, though the spec does seem to call for such support. For simplicity, I've been using your _simple_request('OPTIONS'...) in my private sub-classes, though doing so is incorrect. Show quoted text
> An interesting issue is that there is no way to construct an "OPTIONS *" request with LWP. > HTTP::Request needs an absolute URI with the method. > > So, we would have to make it: > > OPTIONS http://example.com/* > > and then turn "/*" into "*". It would then not be any way to ask for the OPTIONS of the "/*" > resource.
I am not sure how OPTIONS * could function - do not all URIs have to be absolute when issued by the client? My reading of the spec is that the asterisk in question would indeed be as your example.com/* above: I cannot see how it could be otherwise: I read that any after the hostname/port, up to the fragment/query string/path-info, is path part, and has to be delimited from the hostname/port by an oblique. Thanks Lee
  Mon Jun 06 04:06:36 2011 lee [...] leegoddard.net - Correspondence added
Subject: Re: [rt.cpan.org #68644] HTTP::Request::Common OPTIONS
Date: Mon, 06 Jun 2011 10:06:24 +0200
To: bug-HTTP-Message [...] rt.cpan.org
From: Lee Goddard <leegee [...] gmail.com>
Perhaps this should go in a new ticket, but I post it here first to make it easier to dismiss. In HTTP::Request::Common, PUT is treated like GET, when I think it ought to be treated like POST. The HTTP spec says "The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI" What do you think? Thanks Lee
  Tue Nov 29 05:51:19 2011 LGODDARD [...] cpan.org - Correspondence added
Yes, I do consider OPTIONS to be common, as opposed to what the protocol RFC describes as an 'extension method' -- OPTIONS is common to all applications which aim to support the HTTP protocol. This applies to all other methods currently unsupported ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 )
  Tue Jun 02 11:16:49 2015 SZABGAB [...] cpan.org - Correspondence added
I've just encountered the need to send an OPTIONS request to test if my web application satisfied the CORS security feature of Chrome that will send an OPTIONS request before every DELETE request. http://stackoverflow.com/questions/21783079/ajax-in-chrome-sending-options-instead-of-get-post-put-delete It would be nice if OPTIONS was added to the module.
  Tue Jun 02 12:12:49 2015 LGODDARD [...] cpan.org - Correspondence added
On 2015-06-02 11:16:49, SZABGAB wrote: Show quoted text
> I've just encountered the need to send an OPTIONS request to test if > my web application satisfied the CORS security feature of Chrome that > will send an OPTIONS request before every DELETE request. > > http://stackoverflow.com/questions/21783079/ajax-in-chrome-sending- > options-instead-of-get-post-put-delete > > It would be nice if OPTIONS was added to the module.
It would be a miracle. This module is suffering from the same rot that is killing the Perl language. I'd happily supply a patch - either of us could do it in very short time - but I have no reason to believe it would even be read.
  Tue Jun 02 14:49:13 2015 ether [...] cpan.org - Correspondence added
On 2015-06-02 09:12:49, LGODDARD wrote: Show quoted text
> On 2015-06-02 11:16:49, SZABGAB wrote:
> > I've just encountered the need to send an OPTIONS request to test if > > my web application satisfied the CORS security feature of Chrome that > > will send an OPTIONS request before every DELETE request. > > > > http://stackoverflow.com/questions/21783079/ajax-in-chrome-sending- > > options-instead-of-get-post-put-delete > > > > It would be nice if OPTIONS was added to the module.
> > It would be a miracle. This module is suffering from the same rot that > is killing the Perl language. > > I'd happily supply a patch - either of us could do it in very short > time - but I have no reason to believe it would even be read.
I'm reading these tickets, and I have comaint, but given the lack of organized discussion in the libwww-perl group, I do not feel authorized to ship anything but emergency patches at this point.
  Tue Jun 02 15:57:01 2015 lee [...] leegoddard.net - Correspondence added
Subject: Re: [rt.cpan.org #68644] HTTP::Request::Common OPTIONS
Date: Tue, 02 Jun 2015 20:56:53 +0100
To: bug-HTTP-Message [...] rt.cpan.org
From: Lee <leegee [...] gmail.com>
Dear Karen I had no idea it was necessary to mail libwww-perl, thanks — I'll do so. Surely additional features that are backwards-compatible can cause no harm? What I strongly object to is the tone of the original replies to this ticket. Lee
  Thu Mar 30 20:58:07 2017 olaf [...] wundersolutions.com - Correspondence added
Ticket migrated to github as https://github.com/libwww-perl/HTTP-Message/issues/67
  Thu Mar 30 20:58:18 2017 olaf [...] wundersolutions.com - Status changed from 'open' to 'resolved'