This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 228065 - Server is not generating correct mime types
Summary: Server is not generating correct mime types
Status: VERIFIED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: HTML Project (show other bugs)
Version: 7.3
Hardware: PC Windows 8 x64
: P3 normal (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-28 20:56 UTC by jazomand
Modified: 2013-05-09 14:36 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jazomand 2013-03-28 20:56:26 UTC
Embedded Lightweight Web Server serves audio(mp3 and ogg) files inside an HTML5 project type as text mime type.
That makes the server unusable on Firefox and really unestable on Chrome when working with HTML5 Audio elements.
Comment 1 David Konecny 2013-04-01 23:27:30 UTC
You are right. I'm fixing it in web-main#249449:b48bde90b678 and I would appreciate if you could test it on a nightly dev build whether the fix covers all your scenarios or not. When the fix is in a build the message will be automatically append to this issue with the build number. Thanks!
Comment 2 David Konecny 2013-04-02 00:12:29 UTC
In the meantime the only workaround I can suggest is to use external web server option and install some apache server.
Comment 3 Vladimir Riha 2013-04-17 06:17:04 UTC
For some reason the comment hasn't been posted here, but it is already in dev build. You can download it from [1].

I tried mp3/wav and correct mime type is returned, verified in trunk


[1] http://bits.netbeans.org/netbeans/trunk/nightly/latest/

Product Version: NetBeans IDE Dev (Build 201304162301)
Java: 1.7.0_21; Java HotSpot(TM) Client VM 23.21-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11
System: Linux version 3.2.0-40-generic-pae running on i386; UTF-8; en_US (nb)
Comment 4 Marian Mirilovic 2013-05-07 07:45:42 UTC
David (or anybody else), 
could you please proceed with integration into release73 ASAP ? Thanks in advance.
Comment 5 David Konecny 2013-05-07 08:00:20 UTC
The fix was integrated into release73 as a657ee449ac5. hg transplant was saying (falsly) that it is already in release73 so I had to export/import it - I guess that's the manifestation of the problem introduced recently by 'hg graft'.
Comment 6 Martin Janicek 2013-05-07 08:06:36 UTC
(In reply to comment #5)
> The fix was integrated into release73 as a657ee449ac5. hg transplant was saying
> (falsly) that it is already in release73 so I had to export/import it - I guess
> that's the manifestation of the problem introduced recently by 'hg graft'.

You're right David. Sorry for that
Comment 7 David Konecny 2013-05-07 08:09:01 UTC
> You're right David. Sorry for that

Do not worry man, it is not your fault! It's a bug in HG. Have we tried to file the problem to Mercurial team?
Comment 8 Martin Janicek 2013-05-07 08:22:42 UTC
(In reply to comment #7)
> Do not worry man, it is not your fault! It's a bug in HG. Have we tried to file
> the problem to Mercurial team?

Nope, it is as always human-fault (read it as my fault ;)). I have used the 'hg graft' in an incorrect way because I though it works similarly to the 'hg transplant'. I have used these commands:

hg graft someRevisionNumber
hg resolve someFileInConflict.txt
hg ci -m 'Transplantim someRevisionNumber'

..but obviously if you are resolving graft merge conflicts and you don't use 'hg graft --continue', the graft ended in unwanted state where the merge isn't completed correctly.
I wasn't aware of this and though graft is pretty safe operation (like the transplant is) which shows up as an evil-assumption..
Comment 9 David Konecny 2013-05-07 08:54:03 UTC
None of the HG tooling should ever allow to mess up the repository! And having a repository where changeset headers are integrated but changeset content is not is messed up repository, no? So in that light it is hg graft fault - it should be user error prone. And we should report it to them.

When we've started using hg (prior to 1.0 release) there used to be dozens of issues like that - I used to be pretty scarred any time I was pushing changes to a repo as there were cases of people not merging properly their one line change and reverting few days of work of whole team. Again, it was tool's fault. So do not worry too much - anybody else could have done the same mistake.
Comment 10 Quality Engineering 2013-05-08 02:01:26 UTC
Integrated into 'releases', will be available in build *201305072358* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/a657ee449ac5
User: David Konecny <dkonecny@netbeans.org>
Log: changeset: 257527:b48bde90b678
user: David Konecny <dkonecny@netbeans.org>
date: Tue Apr 02 12:23:46 2013 +1300
files: web.common/nbproject/project.properties web.common/src/org/netbeans/modules/web/common/api/WebServer.java web.common/src/org/netbeans/modules/web/common/api/mime.types
description:

#228065 - Server is not generating correct mime types
Comment 11 Vladimir Riha 2013-05-09 14:36:25 UTC
verified in patch2

Product Version: NetBeans IDE 7.3.1 (Build 201302132200)
Java: 1.7.0_21; Java HotSpot(TM) Client VM 23.21-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11
System: Linux version 3.2.0-41-generic-pae running on i386; UTF-8; en_US (nb)