From mat.schaffer at gmail.com Sun Mar 9 20:46:44 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Sun, 9 Mar 2008 20:46:44 -0400 Subject: [Mechanize-users] Mechanize for multi-part form post Message-ID: <91C6B59E-062A-4720-BB28-6DCA0B112CF4@gmail.com> Hi, I'm interested in using Mechanize as a way around manual multipart form creation. But the API is really centered around the idea of a form built from a page. I'd love to see a syntax like: response = agent.post('http://www.mydomain.com/upload', :image => File.new(file), :title => "My image", :description => "an image description") Basically Mechanize#post would just automagically switch when it saw a File object for a post value. I'm actually doing this for flickr uploading, but none of the ruby libraries I've tried so far actually support uploading without headaches. Has work been done on this front? Am I totally off-base? If the answer to both of these is no, perhaps I'll check out the latest mechanize and see if I can work up a patch. Oh also, I know I could use curb for this, but I really like mechanize and also curb isn't jruby compatible. Thanks, Mat From aaron at tenderlovemaking.com Mon Mar 10 15:09:31 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Mon, 10 Mar 2008 12:09:31 -0700 Subject: [Mechanize-users] Mechanize for multi-part form post In-Reply-To: <91C6B59E-062A-4720-BB28-6DCA0B112CF4@gmail.com> References: <91C6B59E-062A-4720-BB28-6DCA0B112CF4@gmail.com> Message-ID: <20080310190931.GA21961@mac-mini.lan> On Sun, Mar 09, 2008 at 08:46:44PM -0400, Mat Schaffer wrote: > Hi, > > I'm interested in using Mechanize as a way around manual multipart > form creation. But the API is really centered around the idea of a > form built from a page. I'd love to see a syntax like: > > response = agent.post('http://www.mydomain.com/upload', > :image => File.new(file), > :title => "My image", > :description => "an image description") > > Basically Mechanize#post would just automagically switch when it saw a > File object for a post value. I'm actually doing this for flickr > uploading, but none of the ruby libraries I've tried so far actually > support uploading without headaches. Yes, I like this syntax. > > Has work been done on this front? Am I totally off-base? If the > answer to both of these is no, perhaps I'll check out the latest > mechanize and see if I can work up a patch. WWW::Mechanize already has a post method, I'd just have to add the logic to auto-detect the IO object and have it automagically post correctly. I like this feature, so I'll work on adding it. :-) -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Mon Mar 10 20:09:18 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Mon, 10 Mar 2008 20:09:18 -0400 Subject: [Mechanize-users] Mechanize for multi-part form post In-Reply-To: <20080310190931.GA21961@mac-mini.lan> References: <91C6B59E-062A-4720-BB28-6DCA0B112CF4@gmail.com> <20080310190931.GA21961@mac-mini.lan> Message-ID: On Mar 10, 2008, at 3:09 PM, Aaron Patterson wrote: >> Has work been done on this front? Am I totally off-base? If the >> answer to both of these is no, perhaps I'll check out the latest >> mechanize and see if I can work up a patch. > > WWW::Mechanize already has a post method, I'd just have to add the > logic > to auto-detect the IO object and have it automagically post correctly. > > I like this feature, so I'll work on adding it. :-) Sweet! I was planning on doing some work on my uploading this evening, so I'l keep you posted if I come up with any interesting developments. Pleasure talking to you as always, Aaron! -Mat From mat.schaffer at gmail.com Mon Mar 10 21:07:14 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Mon, 10 Mar 2008 21:07:14 -0400 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page Message-ID: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> So I found myself wanting to call Mechanize#get with a hash for arguments like this: WWW::Mechanize.new('http://api.flickr.com/services/rest/', {:method => 'flickr.auth.getFrob'... }) Granted, it looks like this isn't supported but it led me to what looks like a bug. Namely that get calls fetch_page(abs_uri, request, cur_page, &block) [mechanize.rb:167]. But the method signature for fetch_page [mechanize.rb:441] is def fetch_page(uri, request, cur_page=current_page(), request_data=[]). What was the intention for the &block on Mechanize#get? I can't find any examples of it getting used in any of the test cases. It'd be cool if I could make use of that parameter as request_data since I think it would be exactly the function I'm looking for. Thanks again, Mat From aaron at tenderlovemaking.com Tue Mar 11 10:03:01 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Tue, 11 Mar 2008 07:03:01 -0700 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> Message-ID: <20080311140300.GA2765@mac-mini.lan> On Mon, Mar 10, 2008 at 09:07:14PM -0400, Mat Schaffer wrote: > So I found myself wanting to call Mechanize#get with a hash for > arguments like this: > > WWW::Mechanize.new('http://api.flickr.com/services/rest/', {:method => > 'flickr.auth.getFrob'... }) > > Granted, it looks like this isn't supported but it led me to what > looks like a bug. Namely that get calls fetch_page(abs_uri, request, > cur_page, &block) [mechanize.rb:167]. But the method signature for > fetch_page [mechanize.rb:441] is def fetch_page(uri, request, > cur_page=current_page(), request_data=[]). You're right. That does look like a bug. Also, this is another syntax I like. Would you be able to put up with: agent.get('http://blah.com/', nil, { :one => 'two' ... }) > > What was the intention for the &block on Mechanize#get? I can't find > any examples of it getting used in any of the test cases. It'd be > cool if I could make use of that parameter as request_data since I > think it would be exactly the function I'm looking for. The problem is that you need to stop reading my code! ;-) IIRC my intent was to yield the page to the block. However there must have been a disconnect between my brain and the keyboard. I'll fix it. -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Tue Mar 11 12:42:59 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Tue, 11 Mar 2008 12:42:59 -0400 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <20080311140300.GA2765@mac-mini.lan> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> Message-ID: On Mar 11, 2008, at 10:03 AM, Aaron Patterson wrote: > You're right. That does look like a bug. Also, this is another > syntax > I like. Would you be able to put up with: > > agent.get('http://blah.com/', nil, { :one => 'two' ... }) This would be okay, but I'd be curious about moving the referrer argument to the end so you don't need the nil. The nil kinda throws off the DSL quality of it all, I think. Sadly, I tried to just patch around it like I thought would work and it didn't. (patch attached) Basically when I hit mechanize.rb:513, it told me that I was giving http_obj.request too many arguments. And I couldn't figure out what http_obj was. Maybe some sort of delegate? I didn't wanna wade through your connection caching code to figure it out. I've been making due with this in the mean time: agent.get(url + "?" + WWW::Mechanize.build_query_string(args)) Which might help you build that get syntax that I'm aiming for. Anyway, I'm living with it, so don't rush into a sub-optimal solution on my account. >> What was the intention for the &block on Mechanize#get? I can't find >> any examples of it getting used in any of the test cases. It'd be >> cool if I could make use of that parameter as request_data since I >> think it would be exactly the function I'm looking for. > > The problem is that you need to stop reading my code! ;-) IIRC my > intent was to yield the page to the block. However there must have > been > a disconnect between my brain and the keyboard. I'll fix it. PEBKAC!!!! :) With any luck, I'll have a flickr api library built around mechanize when this is all done. Which could be fun :) Thanks, Mat -------------- next part -------------- A non-text attachment was scrubbed... Name: get_params.patch Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/acad567e/attachment.obj -------------- next part -------------- From aaron at tenderlovemaking.com Tue Mar 11 17:17:40 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Tue, 11 Mar 2008 14:17:40 -0700 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> Message-ID: <20080311211740.GA6506@mac-mini.lan> On Tue, Mar 11, 2008 at 12:42:59PM -0400, Mat Schaffer wrote: > > On Mar 11, 2008, at 10:03 AM, Aaron Patterson wrote: >> You're right. That does look like a bug. Also, this is another syntax >> I like. Would you be able to put up with: >> >> agent.get('http://blah.com/', nil, { :one => 'two' ... }) > > This would be okay, but I'd be curious about moving the referrer argument > to the end so you don't need the nil. The nil kinda throws off the DSL > quality of it all, I think. Ask an ye shall receive. This now works: page = @agent.get('http://localhost/', { :q => 'hello' }) So does this: @agent.get('http://localhost/') do |page| ... end As well as this: page = @agent.post('http://localhost/file_upload', { :name => 'Some picture', :userfile1 => File.open(__FILE__) }) Any other requests before I make a release? -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Tue Mar 11 20:09:09 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Tue, 11 Mar 2008 20:09:09 -0400 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <20080311211740.GA6506@mac-mini.lan> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> <20080311211740.GA6506@mac-mini.lan> Message-ID: <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> On Mar 11, 2008, at 5:17 PM, Aaron Patterson wrote: > Ask an ye shall receive. This now works: > > page = @agent.get('http://localhost/', { :q => 'hello' }) > > So does this: > > @agent.get('http://localhost/') do |page| > ... > end > > As well as this: > > page = @agent.post('http://localhost/file_upload', { > :name => 'Some picture', > :userfile1 => File.open(__FILE__) > }) > > Any other requests before I make a release? You frickin rule! Seriously dude, you're awesome. Actually, not a request exactly, but I did notice an odd behavior now that you mention http://localhost. It looks like mechanize is set up to have some tricky behavior when referencing localhost. Namely, it seems to be sidestepping the webserver. Just as an example, see the attached script and output that gets pretty different results for localhost and 127.0.0.1. It certainly bit me for about 5 minutes before I noticed what was going on. I haven't really debugged it so I'm not sure if it's mechanize or maybe something in Net::HTTP. I'll look a bit and let you know if I find anything. This is on mechanize-0.7.2. -Mat -------------- next part -------------- A non-text attachment was scrubbed... Name: tester.rb Type: text/x-ruby-script Size: 245 bytes Desc: not available Url : http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/d70a509d/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output.txt Url: http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/d70a509d/attachment.txt From mat.schaffer at gmail.com Tue Mar 11 20:29:27 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Tue, 11 Mar 2008 20:29:27 -0400 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> <20080311211740.GA6506@mac-mini.lan> <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> Message-ID: <962BFE1B-7D35-47A1-A919-190ECCA90AF1@gmail.com> On Mar 11, 2008, at 8:09 PM, Mat Schaffer wrote: > You frickin rule! Seriously dude, you're awesome. > > Actually, not a request exactly, but I did notice an odd behavior > now that you mention http://localhost. It looks like mechanize is > set up to have some tricky behavior when referencing localhost. > Namely, it seems to be sidestepping the webserver. Just as an > example, see the attached script and output that gets pretty > different results for localhost and 127.0.0.1. It certainly bit me > for about 5 minutes before I noticed what was going on. I haven't > really debugged it so I'm not sure if it's mechanize or maybe > something in Net::HTTP. I'll look a bit and let you know if I find > anything. > > This is on mechanize-0.7.2. > -Mat Yep, it's Net::HTTP. Man... I have such a bittersweet relationship with that library. But its interesting to note that jruby gets it right. Probably because jruby's implementation of Net::HTTP is just based on Java's HttpURLConnection. Anyway, unless feel like taking your babysitting of Net::HTTP to a whole new level. Release away! :) -Mat -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: net_http_output.txt Url: http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/91e7e345/attachment-0002.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: net_http_tester.rb Type: text/x-ruby-script Size: 219 bytes Desc: not available Url : http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/91e7e345/attachment-0001.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: net_http_output.jruby.txt Url: http://rubyforge.org/pipermail/mechanize-users/attachments/20080311/91e7e345/attachment-0003.txt From aaron at tenderlovemaking.com Wed Mar 12 14:16:32 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Wed, 12 Mar 2008 11:16:32 -0700 Subject: [Mechanize-users] [ANN] mechanize 0.7.3 Released Message-ID: <20080312181632.GA17770@mac-mini.lan> mechanize version 0.7.3 has been released! * The Mechanize library is used for automating interaction with websites. Mechanize automatically stores and sends cookies, follows redirects, can follow links, and submit forms. Form fields can be populated and submitted. Mechanize also keeps track of the sites that you have visited as a history. Changes: # Mechanize CHANGELOG ## 0.7.3 * Pages are now yielded to a blocks given to WWW::Mechanize#get * WWW::Mechanize#get now takes hash arguments for uri parameters. * WWW::Mechanize#post takes an IO object as a parameter and posts correctly. * Fixing a strange zlib inflate problem on windows * -- Aaron Patterson http://tenderlovemaking.com/ From aaron at tenderlovemaking.com Wed Mar 12 14:17:29 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Wed, 12 Mar 2008 11:17:29 -0700 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> <20080311211740.GA6506@mac-mini.lan> <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> Message-ID: <20080312181729.GB17770@mac-mini.lan> On Tue, Mar 11, 2008 at 08:09:09PM -0400, Mat Schaffer wrote: > On Mar 11, 2008, at 5:17 PM, Aaron Patterson wrote: >> Ask an ye shall receive. This now works: >> >> page = @agent.get('http://localhost/', { :q => 'hello' }) >> >> So does this: >> >> @agent.get('http://localhost/') do |page| >> ... >> end >> >> As well as this: >> >> page = @agent.post('http://localhost/file_upload', { >> :name => 'Some picture', >> :userfile1 => File.open(__FILE__) >> }) >> >> Any other requests before I make a release? > > You frickin rule! Seriously dude, you're awesome. Thanks. I've got to keep my users happy. :-) Its released now. -- Aaron Patterson http://tenderlovemaking.com/ From aaron at tenderlovemaking.com Wed Mar 12 14:22:15 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Wed, 12 Mar 2008 11:22:15 -0700 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <962BFE1B-7D35-47A1-A919-190ECCA90AF1@gmail.com> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> <20080311211740.GA6506@mac-mini.lan> <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> <962BFE1B-7D35-47A1-A919-190ECCA90AF1@gmail.com> Message-ID: <20080312182215.GC17770@mac-mini.lan> On Tue, Mar 11, 2008 at 08:29:27PM -0400, Mat Schaffer wrote: > On Mar 11, 2008, at 8:09 PM, Mat Schaffer wrote: >> You frickin rule! Seriously dude, you're awesome. >> >> Actually, not a request exactly, but I did notice an odd behavior now that >> you mention http://localhost. It looks like mechanize is set up to have >> some tricky behavior when referencing localhost. Namely, it seems to be >> sidestepping the webserver. Just as an example, see the attached script >> and output that gets pretty different results for localhost and 127.0.0.1. >> It certainly bit me for about 5 minutes before I noticed what was going >> on. I haven't really debugged it so I'm not sure if it's mechanize or >> maybe something in Net::HTTP. I'll look a bit and let you know if I find >> anything. >> >> This is on mechanize-0.7.2. >> -Mat > > Yep, it's Net::HTTP. Man... I have such a bittersweet relationship with > that library. But its interesting to note that jruby gets it right. > Probably because jruby's implementation of Net::HTTP is just based on > Java's HttpURLConnection. I wonder how EventMachine would work with this.... I was thinking about switching mechanize from net/http to EventMachine, but EventMachine doesn't have the features I need. I sent in a patch, but didn't really get any responses: http://rubyforge.org/pipermail/eventmachine-talk/2008-March/001754.html I think I'll try again because EventMachine is insanely fast compared to net/http. -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Wed Mar 12 18:44:57 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Wed, 12 Mar 2008 18:44:57 -0400 Subject: [Mechanize-users] Mechanize#get vs Mechanize#fetch_page In-Reply-To: <20080312182215.GC17770@mac-mini.lan> References: <001E35E7-0926-4730-BDE6-7F0413B5D7B5@gmail.com> <20080311140300.GA2765@mac-mini.lan> <20080311211740.GA6506@mac-mini.lan> <1EDEBAEE-C1EA-4C3A-80BE-4F6A999C5D25@gmail.com> <962BFE1B-7D35-47A1-A919-190ECCA90AF1@gmail.com> <20080312182215.GC17770@mac-mini.lan> Message-ID: <6A57A28B-FE8B-45C3-ACCE-227A6F4FB9E8@gmail.com> On Mar 12, 2008, at 2:22 PM, Aaron Patterson wrote: > I wonder how EventMachine would work with this.... I was thinking > about > switching mechanize from net/http to EventMachine, but EventMachine > doesn't have the features I need. I sent in a patch, but didn't > really > get any responses: > > http://rubyforge.org/pipermail/eventmachine-talk/2008-March/ > 001754.html > > I think I'll try again because EventMachine is insanely fast > compared to > net/http. Huh... I wasn't even aware that EventMachine was good for anything other than servers. Might have to take a second look at that. Thanks! Mat From mat.schaffer at gmail.com Sat Mar 15 09:54:54 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Sat, 15 Mar 2008 09:54:54 -0400 Subject: [Mechanize-users] [PATCH] Get requests with non-html referers Message-ID: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> Hey, Aaron. Looks like that get with hash params patch you checked in had some side effects. Specifically, you're testing if a referer is a Page (mechanize.rb:171), but the referer could also be a WWW::Mechanize::File. Like if the last page loaded was xml. Here's a patch that addresses the issue. Thanks again, Mat -------------- next part -------------- A non-text attachment was scrubbed... Name: mechanize_get_with_file_as_referer.patch Type: application/octet-stream Size: 1238 bytes Desc: not available Url : http://rubyforge.org/pipermail/mechanize-users/attachments/20080315/a4157e46/attachment.obj -------------- next part -------------- From aaron at tenderlovemaking.com Sat Mar 15 11:08:13 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Sat, 15 Mar 2008 08:08:13 -0700 Subject: [Mechanize-users] [PATCH] Get requests with non-html referers In-Reply-To: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> References: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> Message-ID: <20080315150813.GA22170@mac-mini.lan> On Sat, Mar 15, 2008 at 09:54:54AM -0400, Mat Schaffer wrote: > Hey, Aaron. Looks like that get with hash params patch you checked in had > some side effects. Specifically, you're testing if a referer is a Page > (mechanize.rb:171), but the referer could also be a WWW::Mechanize::File. > Like if the last page loaded was xml. Here's a patch that addresses the > issue. Ya. I was just looking at this last night. Thanks for the patch! I've applied it, and I will release now. -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Sun Mar 16 21:29:41 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Mon, 17 Mar 2008 10:29:41 +0900 Subject: [Mechanize-users] [PATCH] Get requests with non-html referers In-Reply-To: <20080315150813.GA22170@mac-mini.lan> References: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> <20080315150813.GA22170@mac-mini.lan> Message-ID: <5D02CB6D-9F63-4D60-BCEB-CDA7BE74AA03@gmail.com> On Mar 16, 2008, at 12:08 AM, Aaron Patterson wrote: > Ya. I was just looking at this last night. Thanks for the patch! > I've > applied it, and I will release now. Cool! I was also getting the impression that the whole referer section should be reworked to use the uri of current_page, rather than current_page directly. Just side-step this whole thing. But I didn't know what your plans were surrounding that "Huge hack" where so I stuck with the simple solution. Thanks! Mat From aaron at tenderlovemaking.com Mon Mar 17 10:49:02 2008 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Mon, 17 Mar 2008 07:49:02 -0700 Subject: [Mechanize-users] [PATCH] Get requests with non-html referers In-Reply-To: <5D02CB6D-9F63-4D60-BCEB-CDA7BE74AA03@gmail.com> References: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> <20080315150813.GA22170@mac-mini.lan> <5D02CB6D-9F63-4D60-BCEB-CDA7BE74AA03@gmail.com> Message-ID: <20080317144902.GA20935@mac-mini.lan> On Mon, Mar 17, 2008 at 10:29:41AM +0900, Mat Schaffer wrote: > On Mar 16, 2008, at 12:08 AM, Aaron Patterson wrote: > > Ya. I was just looking at this last night. Thanks for the patch! > > I've > > applied it, and I will release now. > > Cool! I was also getting the impression that the whole referer > section should be reworked to use the uri of current_page, rather than > current_page directly. Just side-step this whole thing. But I didn't > know what your plans were surrounding that "Huge hack" where so I > stuck with the simple solution. Yes. I headed down the direction of reworking the referer section to use the URI rather than the current page. Unfortunately I ran into a problem.... IIRC, the problem was taking into account the HTML base tag. I think it won't be too much work to factor out the base tag stuff, I just wanted to get that change out quickly. I'll take another stab at refactoring that in a week or two. I've got a cold, so I'm trying to take it easy for a bit. :-) -- Aaron Patterson http://tenderlovemaking.com/ From mat.schaffer at gmail.com Tue Mar 18 19:32:06 2008 From: mat.schaffer at gmail.com (Mat Schaffer) Date: Wed, 19 Mar 2008 08:32:06 +0900 Subject: [Mechanize-users] [PATCH] Get requests with non-html referers In-Reply-To: <20080317144902.GA20935@mac-mini.lan> References: <43EAFA83-EA63-4F9B-AAC9-B185465B0B8E@gmail.com> <20080315150813.GA22170@mac-mini.lan> <5D02CB6D-9F63-4D60-BCEB-CDA7BE74AA03@gmail.com> <20080317144902.GA20935@mac-mini.lan> Message-ID: <8EF40C1A-4491-42D4-B25D-6B7292BCCEA0@gmail.com> On Mar 17, 2008, at 11:49 PM, Aaron Patterson wrote: > Yes. I headed down the direction of reworking the referer section to > use the URI rather than the current page. Unfortunately I ran into a > problem.... IIRC, the problem was taking into account the HTML base > tag. I think it won't be too much work to factor out the base tag > stuff, I just wanted to get that change out quickly. Yeah that's exactly the sort of thing I figured you had a better handle on than I. Honestly I didn't even discover the base tag till like last week. > I'll take another stab at refactoring that in a week or two. I've > got a > cold, so I'm trying to take it easy for a bit. :-) I hear you there. Just came of a 3 day stomach flu myself. Rest up and take it easy. -Mat