Bug in Production Download

Support
1

I’m helping my son create a website (with Netlify site name of roccorizzi.netlify.app)
and we are deploying by dragging the site folder to
Netlify App
We have auto-publishing turned on, and deploying to production works just fine.
Kudos to the developers, it’s sweet how smoothly it all works.

However, the issue we’ve discovered is that the Production Download zip file is wrong (or to use a technical term, munged :). Specifically, all of the file names have been converted from MixedCase to alllowercase. So, when I want to locally deploy an older version of the website to debug an issue, the website is completely broken.

Of course, I wouldn’t have discovered this bug if I had set up a local git repo from the beginning, and then not needed the production download zip file. Which I’ve now done.

However, that doesn’t downplay the significance of this bug. One would expect the production download to be an exact copy of what was deployed to production.

I couldn’t find a Netlify bug reporting form, ticketing system or forum, so I’m posting this here. Hopefully, this is the correct place to submit a bug. If not, please let me know the appropriate place/forum.

thanks for you time,
mike

2

Hey Mike, thanks for reaching out!

Hmm, just to make sure I understand the issue correctly, when you go to download the zip file it’s turning all the file names lowercase, when initially it was all mixedCased?

If I’m understanding the issue right, great! If not let me know. I’m going to try reproducing this and open up a bug on our side here.

Really appreciate you reaching out and letting us know!

3

Hi Andrew,

Yes, you’ve described it perfectly!

Let me know if there is anything else I can do to help.

cheers,
mike

4

This is expected behaviour. We normalize names to lowercase. How is this causing an issue? Mind explaining?

5

Clearly someone at Netlify considers changing their customer’s website file names as expected behavior, otherwise, this bug would not exist. Ha. :slight_smile:

Here’s a code snippet to demonstrate the problem more clearly

<div class="col-md-5 offset-md-0   ">
    <div class="block-content">
        <ul class="block-images row">
            <li class="col-md-12 col-sm-12 h6 caption swap-color">
                <img src="**img/RRRwithBootsyIMG_20180716_131620.jpg**" alt="Rocco and Bootsy Collins">
                <br>
                12 year old Rocco with Bootsy Collins
            </li>

        </ul>
    </div>
</div>

And to pre-empt a “counter-argument” that all filenames on the web are supposed to be all lowercase, I present
Exhibit A:

https://en.wikipedia.org/wiki/Kai_Eckhardt

and Exhibit B:

https://en.wikipedia.org/wiki/File:Eckhardt_2015.jpg

In summary,

As a customer of Netlify,
I expect the production download of my website to be an exact copy of what was deployed to production,
so that I can locally run an older version for debugging purposes.

Let me know if you have any additional questions.

cheers,
mike

6

Some additional info for you after an Internet search

7

If it is expected behaviour then it is not a bug—it was specifically designed to do the thing it does.

No one said that. I for one appreciate that not all paths/filenames are lowercase and support that.

Can you point me to the section of Netlify’s documentation where it states this because I can’t find it? The only mention of normalization I can find is in the redirects documentation under Trailing slash (literally removing the trailing slash) which doesn’t apply in this instance.

8

Not documented, but referenced in other threads like this: How to disable "Uppercase URLs are redirected to Lowercase URLs" feature? - #4 by hrishikesh. I personally don’t see a reason for this to be documented as like I mentioned, this is a CDN-internal thing. For the users, this is transparent. If you feel otherwise, let me know.

This is expected behaviour for us as we do that to improve cache hit ratios based on how our CDN works. If this is causing some unexpected issues other than the cosmetic issue mentioned here, we can re-evaluate. But other than that, like some people have mentioned there and now in this thread, this is a controversial discussion and there would not be a single right answer. We did what we could to improve the performance of sites on Netlify in a way that suited us the best. Happy to consider our stance if this breaks or causes some issue, but if not, there won’t be a conclusion for this discussion.

9

First, the issue that I have described is not cosmetic…the current behavior of Netlify’s Production Download of a deploy is not the same code that was deployed. The website code that I extract from the Netlify Production download does not work because the HTML code cannot find the files because Netlify changed the file names. Normally, that is considered a bug.

I respectfully disagree that this is a controversial topic. The World Wide Web works because of universally agreed upon standards enshrined in RFCs found at W3C. The W3C page on URL standards (HTML and URLs) specifically says

“URLs in general are case-sensitive (with the exception of machine names). There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.”

and even has an example demonstrating a mixed-case URL

http://www.w3.org/TR/WD-html4/cover.html

Also in another post (Is there any way to make _redirects case-insensitive? - #2 by hrishikesh) Netlify Support person Hrishikesh says
“URLs are case-sensitive for anything after the domain name”

Does Netlify really intend to violate the HTTP specification that says the path component of a URL (which includes filenames) is considered case-sensitive?

It is all very baffling…perhaps someone can explain why Netlify changes file names in the Production Deploy Download file, but not change the file names that are actually deployed to production? Why are the two deploys different?

I’m genuinely confused as to why Netlify is changing file names. Would love to know the reason.

mike

1 Like
10

I believe @hrishikesh has mentioned the reason above, and it’s also in other threads as linked.

Which isn’t to say I agree with either position, just that reasoning has already been given.

Separate from any argument about “Netlify changing files” or “URL case sensitivity”, I’m confused as to why your workflow relies on you re-downloading files that have been uploaded to Netlify?

Your system is the original source of the files that you’re uploading, and while using “drag & drop deployment” you seem to be treating the ability to download the files as some kind of version control?

1 Like
11

When you download the code from Netlify, the expected use-case is not to deploy it elsewhere or check on localhost. That feature is mainly for debugging purposes to check if your files exist in the deploy. If you really want to run the site elsewhere, it is assumed that you’d have your codebase that you can build anywhere else.

An export from Netlify not working on other servers is not a bug as long as it works on Netlify. We design a feature that best utilizes our CDN systems. It may or may not work the same way on other systems, that doesn’t make this a bug.

I don’t think anyone at Netlify said the URLs are not case-sensitive, or that we’re going against the standards. You’re even quoting me saying the same thing. The controversial discussion here is whether or not we should convert URLs to lowercase for static files only. As mentioned in the thread I linked above, we don’t do that for URLs that are not static files (like Netlify Rewrites which can be proxying to same other server and that server might not be able to parse a case insensitive URL, or Netlify Functions due to more or less same reason). You might not believe how many of these case insensitive URLs are unintentional. You can probably search for posts about having build issues on Netlify due to incorrect case in file names and that should give you an idea how many people don’t consider case sensitivity when linking to files.

I believe you mean the links to the file? If so, we have no reason to change that since we resolve that to the same URL.

All this to say, there’s no bug here. Netlify does what’s best for it’s systems. Is it the best for all? No. But, does it work well and cause no issues to the users? Yes, I believe for the most part.

If this is still somehow causing issues for your workflow, I’m sorry to say, Netlify is not the product for you.