New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 261 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Feb 2015



Sign in to add a comment

Throw error if file upload path is not canonical

Reported by harry.pe...@gmail.com, Mar 7 2013

Issue description

* "Symptoms - What the problem?"

We run an automated test which uploads some files (both text and binary) to a site, and then downloads them again to check the upload has worked.  This has worked fine for several months, and recently started failing.  We think it's the latest update to chrome itself that breaks things.  Reverting to the last version of Chromedriver does not fix the issue.

The file's content seems to be made up of null bytes instead of the expected text:

AssertionError: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' != "It's\r\n\r\nThe rapture for bits!\r\n\r\n:-)\r\n\r\n"

* "Does it happen every time you run the test? If not, how frequently?"

every time. Tested on both Windows XP and Vista.

* "Are you able to reproduce the failure on other browsers?"

Firefox works fine.  Chromium on Ubuntu works fine


* "Which OS, browser and version of the browser are you using? This is vital."

Broken: Chrome 25.0.1364.97 m on XP
Broken: Chrome 25.0.1364.152 m on Vista
Chomedriver chromedriver_win_23.0.1240.0.zip  and chromedriver_win_26.0.1383.0.zip both broken

* "Steps to reproduce:"
need a server that will accept an uploaded file, and allow you to download it again
upload file, text or binary.
compare expected contents

 
Chrome Version 25.0.1364.152 m also fails on XP

What version of Selenium?

Also, what combinations of Chrome & Chrome Driver are you using? Ensure that the driver is at the same version as Chrome itself.
Hi there, we're using the latest selenium (2.31 IIRC), and I've mentioned the two different versions of chromedriver we've tried...
Project Member

Comment 4 by baran...@gmail.com, Mar 7 2013

Cc: kkania@google.com
Labels: Browser-Chrome
I work with the original reporter of this bug.  Is there anything else you need to repro/triage this?
A little more information -- we're using the Python bindings, and I can confirm that the version is 2.31.0
Project Member

Comment 7 by kkania@google.com, Mar 15 2013

Cc: -kkania@google.com
Labels: -Type-Defect -Priority-Medium -Status-Untriaged -Browser-Chrome Pri-2
Summary: Cannot upload file (was: Chrome on windows cannot upload a file)
Project Member

Comment 8 by kkania@google.com, Mar 15 2013

Owner: kkania@chromium.org
Let me see if I can reproduce the problem.

Comment 9 by kkania@chromium.org, Mar 15 2013

Owner: ----
Status: NeedsClarification
Hmm, this worked for me. Does the file input show the right filename? Can you add your chromedriver.log?


Here's what I did. Anything seem different from what you tried?

setup:
Chrome 26.0.1410.33
ChromeDriver 26
windows 7

test.html:
<html>
<form action="gimme" enctype="multipart/form-data" method="post">
<input type="file" name="datafile" size="40">
<input type="submit" value="Send">
</form>
</html>


python:
>>> from selenium import webdriver
>>> d = webdriver.Remote('http://localhost:9515', {})
>>> d.get('http://localhost:33333/test.html')
>>> with open('C:\\temp\\hi.txt', 'w') as f:
>>>    f.write('ok')
>>> d.find_element_by_tag_name('input').send_keys('C:\\temp\\hi.txt')
>>> d.find_elements_by_tag_name('input')[1].click()


The server received this post body:
------WebKitFormBoundary0EQ47dyFoAmu1FPe
Content-Disposition: form-data; name="datafile"; filename="hi.txt"
Content-Type: text/plain

ok
------WebKitFormBoundary0EQ47dyFoAmu1FPe--

Thanks for checking that, it's much appreciated. I can confirm that the filename is correctly set, and my chromedriver.log is attached, along with the file we're trying to upload (perhaps it's the newlines or something?)

The only obvious difference I can see is that we're using the current production Chrome build 25.0.1364.172 rather than your version 26.  We are also using Chromedriver 26.0.1383.0, which I guess is a potential issue, but I don't see a version 25 Chromedriver on the downloads page.
chromedriver.log
87.2 KB View Download
upload_me.txt
34 bytes View Download
I tried Chrome 25 with the specific file you used, but this also worked for me. Here's a couple more ideas:

-What's your enctype for your form?
-Is there a way for me to reproduce your problem easily? Can you use a simple test page and a simple python server and reproduce the issue?


Sorry for the slow response.  The enctype is "multipart/form-data", same as yours.  I'm trying to see what I can do about creating a minimal repro...
No problem. You may also want to try using ChromeDriver2 and see if the file upload works for you. This however requires Chrome 27, which is currently in dev channel. This might be interesting to try, just to see if it works though.
Still working on a full repro, but here's the client-side code:

        browser = webdriver.Chrome()
        browser.get(Url.LOGIN)
        username_field = browser.find_element_by_id('id_username')
        username_field.send_keys(username)
        password_field = browser.find_element_by_id('id_password')
        password_field.send_keys(password)
        browser.find_element_by_id('id_login').click()

        browser.find_element_by_link_text('Files').click()
        browser.find_element_by_link_text('/').click()
        browser.find_element_by_link_text('tmp/').click()

        filename = os.path.join(
            os.path.dirname(__file__),
            '..', 'test_files', 'upload_me.txt'
        )
        browser.find_element_by_id('id_upload_filename').send_keys(filename)
        while not browser.find_element_by_id("id_upload_button").is_displayed():
            time.sleep(1)
        browser.find_element_by_id('id_upload_button').click()

One interesting difference with your code -- I'm using selenium.webdriver.Chrome
Trying ChromeDriver2 now...
Couldn't start the browser -- I got 

    WebDriverException: Message: u'unknown error: no chrome binary at \n  (Driver info: chromedriver=0.4,platform=Windows NT 6.1 SP1 x86_64)'
Project Member

Comment 17 by kkania@google.com, Mar 20 2013

Whoops, there's a bug in the python bindings (http://code.google.com/p/selenium/issues/detail?id=5377)

Until next version of selenium is released, do:

o = webdriver.chrome.options.Options()
o.binary_location = None
d = webdriver.Chrome('path_to_chromedriver.exe', chrome_options=o)
Managed to try chromedriver2 -- it required installing a beta version of chrome (27).

Unfortunately doesn't seem to fix the problem, if anything it is worse in that it doesn't even seem to be able to /try/ and upload the file.

A few smoke tests suggest it has other bugs which affect interactions with other areas of our system, so it's a no-go for us.

Will try and knock up a little minimal repro site for the basic upload problem.

hp
Alright, that would be great. It'd be very helpful to be able to reproduce the problem on our end.
lol, predictably the first attempt at a minimal repro fails to show the bug.  we're digging deeper...
hm, looks like the production app, which is in Django, sees an empty FILES dict... the minimal repro is in flask.  will switch it...
I think I found the problem!  We were submitting a non-absolute path to the file element:

filename = os.path.join(
    os.path.dirname(__file__),
    '..', 'test_files', 'upload_me.txt'
)

It was fixed by calling os.path.abspath on the result.


So the bug, if you want to keep it / accept it, should be  "chromedriver cannot handle relative paths for file upload elements"

or perhaps  "cannot handle non-canonical paths"...
Project Member

Comment 24 by kkania@google.com, Apr 11 2013

Owner: kkania@chromium.org
Status: Started
Summary: Throw error if file upload is not absolute or doesn't exist (was: Cannot upload file)
Great news! I think on the chromedriver side we should only allow absolute file paths. Perhaps on the client side in the webdriver library it makes sense to accept a relative and convert it to an absolute. If we accept relative, the user has to keep in mind that the relative path is according to whatever directory the chromedriver server was started with, and not the test's current directory.

I'll put up a patch to throw an error if the path is not absolute or if the path doesn't exist.
Just to clarify -- the path in our example is *not* a relative path -- it just contains some relative traversals.  Something like:

/home/me/stuff/things/../other_things/file_to_upload.txt

I gather that, strictly speaking, that *is* an absolute path, it's just non-canonical.

So the rule should be: "throw error if file upload path is non-canonical"
Project Member

Comment 26 by kkania@google.com, Apr 11 2013

Ah, thanks.
Status: ToBeReleased
Summary: Throw error if file upload path is not canonical (was: Throw error if file upload is not absolute or doesn't exist)
ok, now we check the path is canonical; will be in next release
Excellent, thanks!
Project Member

Comment 29 by kkania@google.com, May 31 2013

Status: Closed
 unknown error: path is not canonical: app/../spec/files/hamlet_cover.jpg
        (Session info: chrome=33.0.1750.29)
        (Driver info: chromedriver=2.8.240825,platform=Linux 3.11.0-15-generic x86_64)

Status: Fixed

Sign in to add a comment