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)



Subject: HTTP::Request::Common OPTIONS
Download (untitled) / with headers
text/plain 268b
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
Download (untitled) / with headers
text/plain 446b
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.
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>
Download (untitled) / with headers
text/plain 1.3k
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
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>
Download (untitled) / with headers
text/plain 369b
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
Download (untitled) / with headers
text/plain 314b
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 )
Download (untitled) / with headers
text/plain 357b
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.
Download (untitled) / with headers
text/plain 648b
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.
Download (untitled) / with headers
text/plain 911b
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.
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>
Download (untitled) / with headers
text/plain 249b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.