[wp-hackers] stop HTTP requests made behind one's back

[Jacob Santos]

If you require any hooks to implement the plugin, then I think the core 
committers won't mind adding them (disclaimer: I do not speak for those 
with commit access, so they may or may not agree to adding hooks). 
Actual proxy support, I believe would be ideal (the cheap hack with 
adding a filter for cURL didn't work out as well as I thought, 
whats-his-face knows, actually I do know his name, but he is on my shit 
list, so I'm not going to speak of him).

The goal is to implement features as much as possible in every 
transport. I've found, from the work of others, when the SSL support was 
added that it isn't always the case. The fopen transport (not the 
streams) does not support sending headers, so is therefore limited in 
what it can do as well.

Well, I meant to say, good luck.

PS: It isn't so much my code as it is WordPress code, because so many 
people have meshed their code and hands in it. I just have a vested 
interest in it, because it is my precious.

Jacob Santos

Doug Stewart wrote:
> On Tue, Feb 17, 2009 at 11:41 PM, Jacob Santos <wordpress at santosj.name>wrote:
>
>   
>> Yeah, you know, I could have spent another week or two implementing proxy
>> support, but I'm just like, "You know, those people probably amount to only
>> a small fraction of the users, so why should I waste my time?" That and the
>> fact that I don't tend to cut myself, unless I've done something socially
>> awkward. From the complaining of other developers about the pain and
>> suffering of implementing proxy support, I'll keep away from it.
>>
>> That said, there is nothing preventing you (either of you or anyone else
>> with ability to do so) from creating a patch that adds proper proxy support.
>> If you do it well enough, I might send you a gift (disclaimer: I'm not going
>> to send you a gift) and you'll have my gratitude (that is free and has not
>> monetary redeemable value).
>>
>> It serves no purpose for me, which is the most important reason why I
>> didn't implement it nor will I implement it in the future. I do not host
>> WordPress behind a proxy, therefore well, it would be impossible for me to
>> develop a solution anyway, because I would fail to be able to test whether
>> or not it works (for that proxy and version).
>>
>> So I mean, those fraction of users whose host has screwed them will
>> appreciate it. There there are you two.
>>
>> Jacob Santos
>>
>>
>>     
> Jacob:
> Whoah.  Wasn't trying to dump on your hard work in the slightest -- you've
> done a yeoman's share, as far as I'm concerned, in getting the HTTP
> transports thing going.  Definitely goes a long way towards making WordPress
> dead-simple to admin and keep up to date.
>
> What I'm trying to do, though, is keep that simplicity in place for my
> corporate client who unfortunately doesn't have the option of running a
> transparent proxy.  I want to leverage your hard work and, well, make it
> work so that the marcomm folks tasked with adminning the site don't have to
> hit me up for plugin updates every time.
>
> I can do all sorts of add_filters to disable the different transports (what
> I'm having to resort to now) but I'd far rather just have cURL, fopen, etc.
> respect a proxy.  I'll take a look at the code in the next couple of days
> and see if I can't make it work BTF.  And if anyone else on the list has
> ideas as to how best to make that happen, I'm all ears.
>
>